Git … La herramienta más popular y común utilizada por los programadores en el mundo de la programación.
Olvídate de esta herramienta por un momento y solo mira la imagen que se muestra a continuación…
Flashback… ¿Te estás riendo? (Si tu eres….)
La imagen de arriba te recuerda tu viaje como desarrollador. Así es como intentaste mantener la copia de seguridad de tus archivos cuando tenías miedo de hacer algo mal en tu proyecto. Seguiste este enfoque tradicional pensando que podrías crear un lío en tu proyecto.
Crea algunos archivos en su proyecto, realiza algunos cambios, implementa algo nuevo y luego copia los archivos y les da el nombre blogPost_new. Nuevamente realiza algunos cambios, crea otra copia con otro nombre de archivo blogPost_backup. Esto continúa y su directorio ahora está lleno de múltiples archivos para un solo proyecto. Los archivos de su proyecto son blogPost_old, blogPost_one, blogPost_two, blogPost_backup, blogPost_final, etc.
Después de un par de días, abre su proyecto. Desea verificar lo que hizo en la copia anterior, pero cuando ve toneladas de archivos en su proyecto, se confunde. Ahora no puede identificar qué archivo hace qué y cuál es la secuencia de estos archivos. ¿Qué archivo se estaba ejecutando sin problemas, qué archivos tenían qué tipo de cambios, por qué se cambió el archivo y qué archivo no tiene ningún propósito en su proyecto?
No está solo, y todos hemos estado allí en algún momento de nuestra carrera de desarrollo. Es un gran dolor verificar el código en los archivos manualmente para identificar su propósito.
Ahora es posible que haya entendido la importancia de Git (si es programador y está familiarizado con esta herramienta) en la vida de los programadores. Te salva el día y hace que la vida de los equipos de desarrollo de software sea mucho más fácil.
Es muy fácil administrar su código con Git, y también es fácil corregir su error si algo sale mal. Hoy en día, la mayoría de los programadores (especialmente los novatos) conocen su importancia.
Es posible que haya utilizado varios comandos en git… git add, git push, git pull, git commit, etc., pero si le preguntamos cómo funcionan las cosas detrás de escena y cómo se ve el flujo de Git, entonces cuál sería su respuesta…
La mayoría de nosotros sabemos que no sabemos…
Hoy en este blog vamos a explorar un poco más esta increíble herramienta. Discutiremos en profundidad cómo funciona Git internamente.
Tome su silla, siéntese, relájese y dedique su fin de semana o un par de horas para conocer un poco más su herramienta favorita.
Una introducción rápida
En caso de que no esté familiarizado con esta herramienta, lea el blog Una guía definitiva para Git y Github .
En palabras simples, Git mantiene la copia de seguridad de su proyecto. Realiza un seguimiento de su código fuente tomando una especie de instantánea de ellos. Asigna un valor único (hash SHA-1) a cada instantánea para diferenciarlas. En palabras simples, Git crea puntos de guardado en sus archivos para que pueda revisarlos o recuperarlos cuando lo desee.
Vayamos al punto principal… la funcionalidad principal de Git. Cómo Git maneja tus archivos y el flujo de trabajo de los mismos.
Estados en Git
La funcionalidad principal de Git funciona principalmente en tres estados de archivo: estado modificado , estado preparado o estado confirmado . Si incluye un repositorio remoto, puede dividir su funcionalidad principal en cuatro estados. Sus archivos pueden estar en cualquiera de los estados. Discutiremos cada uno de ellos, pero para una mejor comprensión, vamos a tomar un ejemplo de la vida real.
Considere un escenario en el que se le pide que cree un bonito álbum de fotos con algún título o mensaje junto con las imágenes. ¿¿Cómo lo harías tú??
Lo más probable es que realice las acciones que se indican a continuación…
- Tomará algunas fotos para incluirlas en su álbum de fotos. Aún no lo ha pegado en su álbum, por lo que no afectará su álbum de fotos. Tiene la libertad de filtrar las imágenes que desea incluir en su álbum de fotos. Si no ha hecho clic en una buena imagen, también tiene la opción de volver a tomar la misma imagen si es necesario.
- En el siguiente paso, filtrará las imágenes que desea incluir y las imprimirá. Imagina que los colocas junto a la página vacía de tu álbum. Básicamente, está preparando estas fotos (creando una especie de área de preparación) para pegarlas en su álbum de fotos, pero aún no lo ha hecho.
- Una vez que esté listo con su foto, puede pegarla en su álbum de fotos con algún mensaje o título que describa el momento del evento relacionado con la foto.
En cualquier momento puede pasar las páginas de su álbum y puede recordar cómo se veían las cosas en ese momento específico. Podemos relacionar este ejemplo con los cuatro estados en Git, y podemos entenderlo mucho mejor. Cómo….?? Hablemos de eso.
1. Estado modificado
En este estado, sus archivos se modifican, pero los cambios no se guardan. No le indicas a Git que supervise estos archivos. Básicamente, estos son archivos no confirmados. Tomar la foto es como hacer cambios en sus archivos. Usted crea archivos, escribe código para agregar algunas funciones o elimina los archivos. Está preparando estos archivos para guardarlos en la confirmación de Git.
Estos archivos no se guardan de forma permanente y su trabajo aún está en progreso. En cualquier momento puede escribir, reescribir, borrar o hacer cambios en su archivo.
2. Estado escenificado
En este estado, sus archivos están preparados para confirmarse en el repositorio .git. Estos archivos no están confirmados y solo están preparados para confirmarse en su estado o versión actual. Simplemente autoriza explícitamente a Git a monitorear las versiones de los archivos.
Git no ha confirmado estos archivos, por lo que incluso después de agregar los archivos al área de preparación, aún tiene la opción de modificar sus archivos. Puede realizar modificaciones y puede agregar esta modificación al área de preparación. Esto es como hacer clic en algunas imágenes nuevas y luego decidir pegarlas en el álbum de fotos.
3. Estado comprometido
En esta etapa final, guarda con éxito los archivos en el repositorio .git y crea una confirmación para ellos. Crear la confirmación es como pegar tus fotos en el álbum de fotos. En esta fase final, registra la versión preparada de su archivo en el directorio de Git.
Escribes un mensaje o el título con estas imágenes para dar información de lo que estas imágenes significan para ti. Confirmar mensajes en Git funciona de la misma manera. Escribe un mensaje de confirmación para dar información sobre los cambios que ha realizado en su código o las características que ha agregado a su código.
Siempre escriba un mensaje de confirmación descriptivo que describa claramente qué características ha agregado, qué cambios ha realizado o qué error ha resuelto en su base de código.
Ahora hablemos de las ubicaciones de los archivos para sus archivos cuando esté trabajando con sus archivos. Según el estado de un archivo, discutiremos la ubicación donde Git lo colocará.
Ubicaciones de archivos
Para diferentes estados, las ubicaciones de su archivo serán diferentes. Vamos a discutir el flujo de trabajo completo según el estado y las ubicaciones del archivo.
1. Directorio de Trabajo
Cuando crea cualquier carpeta en su sistema, reside en el directorio de trabajo o carpeta local o en su espacio de trabajo. Básicamente, el directorio de trabajo es la carpeta local para los archivos de su proyecto. Ahora es posible que haya entendido que los archivos modificados residen en el directorio de trabajo.
No se confunda entre el directorio de trabajo y el directorio .git. El directorio de trabajo es creado por el usuario y. El directorio git es creado por Git.
2. Área de preparación
Sus archivos en el estado provisional residen en el área provisional. Básicamente, el área de preparación es el «índice» en el lenguaje de Git ubicado en el directorio .git. Almacena la información sobre los archivos que están en cola para ser confirmados.
3. Directorio Git
- Este directorio es el corazón de Git donde ocurre toda la magia. Los archivos en estado confirmado residen en este directorio.
- El directorio .git lo crea Git y almacena los archivos que el usuario confirma o indica que debe monitorear. La carpeta .git almacena las bases de datos de objetos y los metadatos de los archivos.
- El comando git clone seguido de la URL crea una copia local del repositorio en su espacio de trabajo.
- El comando add agrega los archivos del espacio de trabajo al índice o al área de ensayo. El archivo se prepara y se marca para ser confirmado pero aún no confirmado.
- Cuando ejecuta comandos de confirmación en todos los archivos que están preparados, sus cambios se confirmarán en el repositorio local.
Ahora, eche un vistazo a la imagen que se muestra a continuación para comprender el flujo de trabajo completo…
La imagen de arriba se explica por sí misma y muestra un flujo de trabajo completo. Es posible que haya entendido cuál es el propósito de cada comando en Git. Algunas cosas, de la imagen de arriba nos gustaría explicar aquí para que su concepto sea más claro.
En la imagen de arriba, el comando git fetch obtiene los archivos del repositorio remoto al repositorio local, pero aún no a su espacio de trabajo. Para obtener el archivo actualizado del repositorio local a su espacio de trabajo, ejecute el comando git merge . Sus archivos en su espacio de trabajo local se actualizarán a lo que está en el repositorio remoto. Para realizar la operación de bot a la vez, puede ejecutar el comando git pull .
Ahora la pregunta es… si podemos hacer todo en un solo comando git pull entonces ¿por qué necesitamos ejecutar dos comandos separados git fetch y git merge?
La respuesta es… ejecutar dos comandos separados nos permite comparar archivos antes de obtener la última versión de los archivos. En otras palabras, puede obtener los archivos de un repositorio remoto usando el comando git fetch y luego puede ejecutar el comando git diff HEAD para verificar cuáles son las diferencias entre los archivos que existen en el directorio de trabajo y los archivos que existen en el repositorio local. En función de las diferencias, puede decidir si desea fusionar los archivos o no.
El comando git diff (sin cabeza) le indica la diferencia entre los archivos que existen en el directorio de trabajo y los archivos que están preparados para la confirmación. Este comando básicamente le dice que lo que aún podría agregar al escenario para la confirmación adicional, que aún no lo ha hecho.
Internos de Git
Cuando abre un proyecto inicializado por Git, se encuentra con un directorio .git . Este es el lugar donde ocurre toda la magia y en esta sección, discutiremos la estructura interna de .git.
Echando un vistazo más de cerca a este directorio, encontrará cuatro subdirectorios importantes. Analicemos el papel de estos cuatro subdirectorios.
1. objetos: este directorio actúa como una base de datos y almacena todos los archivos de repositorios. Su contenido está codificado y comprimido.
2. referencias: las referencias se han almacenado como archivos de texto normales en el directorio .git/refs y este archivo almacena el puntero en objetos de confirmación. En palabras simples, si necesita manipular un objeto, debe recordar el hash del objeto. Memorizar estos hashes es difícil, así que git tiene una referencia. Estas referencias contienen el hash de un objeto de confirmación.
3. HEAD: este archivo contiene la ruta a la referencia que apunta a la rama actual en la que está trabajando.
4. config : en este archivo, puede encontrar la configuración del repositorio.
Algunos comandos de plomería que debe conocer
Casi todos los comandos de git, como git add, git commit, se componen de algunos comandos básicos de bajo nivel. Estos comandos se llaman comandos de plomería (sabemos que esta es una palabra nueva para usted… ).
Eche un vistazo a la imagen que se muestra a continuación, y luego la explicaremos en detalle…
- Suponga que tiene un directorio de trabajo y lo inicializa con Git. Después de inicializar su proyecto si crea o coloca un archivo en él, Git crea el árbol de trabajo , y en este momento, cuando ejecuta el comando de estado de git , ve algo como esto…
- Cuando sus archivos están preparados, git crea un blob. Blob contiene el contenido del archivo en formato binario. A este blob se le asigna un valor hash de 40 caracteres (Sha 1 hash) para que pueda identificarse de forma única. Después de eso, este blob se guardará en la base de datos de objetos en el repositorio de Git.
- Habrá varios blobs en el área de preparación, por lo que Git crea un árbol para preparar los blobs que se van a confirmar. Un árbol contiene el puntero al blob y lo denomina A. Esta será la instantánea de todos los archivos que desea confirmar.
- Antes de confirmar los archivos, tomamos la identificación del usuario para rastrear quién realizó la confirmación. Tree almacena el autor y el commiter, y también el mensaje de este commit.
Pensamiento final
Hicimos todo lo posible para que se familiarice con la estructura interna de Git y ahora puede tener una idea sobre el flujo de trabajo de Git. Cómo funcionan los comandos de git bajo el capó y qué operaciones se realizan internamente.
Publicación traducida automáticamente
Artículo escrito por anuupadhyay y traducido por Barcelona Geeks. The original can be accessed here. Licence: CCBY-SA