Primeros pasos con Git: una guía completa para principiantes

En lugar de una introducción

¡Hola! Hoy vamos a hablar sobre un sistema de control de versiones, a saber, Git. No tienes nada que ver con la programación si no sabes/entiendes Git. Pero la belleza es que no tienes que tener todos los comandos y características de Git en tu cabeza para poder emplearlos continuamente. Necesita conocer un conjunto de comandos que lo ayudarán a comprender todo lo que está sucediendo.

Conceptos básicos de Git

Git es un sistema de control de versiones distribuido para nuestro código. ¿Por qué lo necesitamos? Los equipos distribuidos necesitan algún tipo de sistema para administrar su trabajo. Es necesario para realizar un seguimiento de los cambios que se producen a lo largo del tiempo. Es decir, necesitamos poder ver paso a paso qué archivos han cambiado y cómo. Esto es especialmente importante cuando investiga qué cambió en el contexto de una sola tarea, lo que hace posible revertir los cambios.

Instalando Git

Instalemos Java en su computadora.

Instalación en Windows

Como de costumbre, debe descargar y ejecutar un archivo exe. Aquí todo es simple: haga clic en el primer enlace de Google , realice la instalación y listo. Para ello, utilizaremos la consola bash que nos proporciona Windows. En Windows, debe ejecutar Git Bash. Así es como se ve en el menú Inicio: Ahora, este es un símbolo del sistema con el que puede trabajar. Para evitar tener que ir a la carpeta con el proyecto cada vez para abrir Git allí, puede abrir el símbolo del sistema en la carpeta del proyecto con el botón derecho del mouse con la ruta que necesitamos:

Instalación en Linux

Por lo general, Git es parte de las distribuciones de Linux y ya está instalado, ya que es una herramienta que se escribió originalmente para el desarrollo del kernel de Linux. Pero hay situaciones en las que no lo es. Para verificar, debe abrir una terminal y escribir: git --version. Si obtiene una respuesta inteligible, entonces no es necesario instalar nada. Abra una terminal e instale Git en Ubuntu . Estoy trabajando en Ubuntu, así que puedo decirte qué escribir para él: sudo apt-get install git.

Instalación en macOS

Aquí también, primero debe verificar si Git ya está allí. Si no lo tiene, la forma más fácil de obtenerlo es descargar la última versión aquí . Si Xcode está instalado, Git definitivamente se instalará automáticamente.

Configuración de Git

Git tiene configuraciones de usuario para el usuario que enviará el trabajo. Esto tiene sentido y es necesario, porque Git toma esta información para el campo Autor cuando se crea una confirmación. Configure un nombre de usuario y una contraseña para todos sus proyectos ejecutando los siguientes comandos:

git config --global user.name "Ivan Ivanov"
git config --global user.email ivan.ivanov@gmail.com

Si necesita cambiar el autor de un proyecto específico, puede eliminar "--global". Esto nos dará lo siguiente:

git config user.name "Ivan Ivanov"
git config user.email ivan.ivanov@gmail.com

Un poco de teoría...

Para profundizar en el tema, debemos presentarle algunas palabras y acciones nuevas...

• repositorio git
• comprometerse
• rama
• unir
• conflictos
• jalar
• empujar
• cómo ignorar algunos archivos (.gitignore)

Etcétera.

Estados en Git

Git tiene varias estatuas que deben entenderse y recordarse:

• sin seguimiento
• modificado
• escenificado
• comprometido

¿Cómo debes entender esto?

Estos son los estados que se aplican a los archivos que contienen nuestro código:

1. Un archivo que se crea pero aún no se agrega al repositorio tiene el estado "sin seguimiento".
2. Cuando realizamos cambios en archivos que ya se han agregado al repositorio de Git, su estado es "modificado".
3. Entre los archivos que hemos cambiado, seleccionamos los que necesitamos, y estas clases se cambian al estado "por etapas".
4. Se crea una confirmación a partir de archivos preparados en el estado provisional y va al repositorio de Git. Después de eso, no hay archivos con el estado "preparado". Pero todavía puede haber archivos cuyo estado sea "modificado".

Esto es lo que parece:

¿Qué es un compromiso?

Una confirmación es el evento principal cuando se trata de control de versiones. Contiene todos los cambios realizados desde que comenzó la confirmación. Las confirmaciones están vinculadas entre sí como una lista vinculada individualmente. Más específicamente: hay un primer compromiso. Cuando se crea la segunda confirmación, sabe lo que viene después de la primera. Y de esta manera, la información puede ser rastreada. Un compromiso también tiene su propia información, los llamados metadatos:

• el identificador único del compromiso, que se puede usar para encontrarlo
• el nombre del autor de la confirmación, quien la creó
• la fecha en que se creó la confirmación
• un comentario que describe lo que se hizo durante la confirmación

Así es como se ve:

¿Qué es una sucursal?

Una rama es un puntero a algún compromiso. Debido a que una confirmación sabe qué confirmación la precede, cuando una rama apunta a una confirmación, todas las confirmaciones anteriores también se aplican a ella. En consecuencia, podríamos decir que puedes tener tantas ramas como quieras apuntando al mismo compromiso. El trabajo ocurre en ramas, por lo que cuando se crea una nueva confirmación, la rama mueve su puntero a la confirmación más reciente.

Comenzando con Git

Puede trabajar solo con un repositorio local y también con uno remoto. Para practicar los comandos requeridos, puede limitarse al repositorio local. Solo almacena toda la información del proyecto localmente en la carpeta .git. Si estamos hablando del repositorio remoto, toda la información se almacena en algún lugar del servidor remoto: solo se almacena localmente una copia del proyecto. Los cambios realizados en su copia local se pueden enviar (git push) al repositorio remoto. En nuestra discusión aquí y más abajo, estamos hablando de trabajar con Git en la consola. Por supuesto, puede usar algún tipo de solución basada en GUI (por ejemplo, IntelliJ IDEA), pero primero debe averiguar qué comandos se están ejecutando y qué significan.

Trabajar con Git en un repositorio local

A continuación, le sugiero que siga y realice todos los pasos que hice mientras leía el artículo. Esto mejorará su comprensión y dominio del material. Bueno, ¡buen provecho! :) Para crear un repositorio local, debe escribir:

git init

Esto creará una carpeta .git en el directorio actual de la consola. La carpeta .git almacena toda la información sobre el repositorio de Git. No lo elimine;) A continuación, los archivos se agregan al proyecto y se les asigna el estado "Sin seguimiento". Para consultar el estado actual de tu trabajo, escribe esto:

git status

Estamos en la rama principal, y aquí permaneceremos hasta que cambiemos a otra rama. Esto muestra qué archivos han cambiado pero aún no se han agregado al estado "preparado". Para agregarlos al estado "preparado", debe escribir "git add". Tenemos algunas opciones aquí, por ejemplo:

• git add -A: agrega todos los archivos al estado "preparado"
• agrega git — agregar todos los archivos de esta carpeta y todas las subcarpetas. Esencialmente, esto es lo mismo que el anterior.
• git add <nombre de archivo>: agrega un archivo específico. Aquí puede usar expresiones regulares para agregar archivos de acuerdo con algún patrón. Por ejemplo, git add *.java: esto significa que solo desea agregar archivos con la extensión java.

Las dos primeras opciones son claramente simples. Las cosas se ponen más interesantes con la última incorporación, así que escribamos:

git add *.txt

Para verificar el estado, usamos el comando que ya conocemos:

git status

Aquí puede ver que la expresión regular ha funcionado correctamente: test_resource.txt ahora tiene el estado "preparado". Y finalmente, la última etapa para trabajar con un repositorio local (hay una más cuando se trabaja con un repositorio remoto ;)) — crear una nueva confirmación:

git commit -m "all txt files were added to the project"

El siguiente es un gran comando para ver el historial de confirmaciones en una rama. Hagámosle uso:

git log

Aquí puede ver que hemos creado nuestro primer compromiso e incluye el texto que proporcionamos en la línea de comando. Es muy importante comprender que este texto debe explicar con la mayor precisión posible lo que se hizo durante este compromiso. Esto nos ayudará muchas veces en el futuro. Un lector inquisitivo que aún no se ha quedado dormido puede preguntarse qué pasó con el archivo GitTest.java. Averigüémoslo ahora mismo. Para hacer esto, usamos:

git status

Como puede ver, todavía está "sin seguimiento" y está esperando en las alas. Pero, ¿y si no queremos añadirlo al proyecto en absoluto? A veces eso sucede. Para hacer las cosas más interesantes, intentemos ahora cambiar nuestro archivo test_resource.txt. Agreguemos algo de texto allí y verifiquemos el estado:

git status

Aquí puede ver claramente la diferencia entre los estados "sin seguimiento" y "modificado". GitTest.java está "sin seguimiento", mientras que test_resource.txt está "modificado". Ahora que tenemos archivos en el estado modificado, podemos examinar los cambios realizados en ellos. Esto se puede hacer usando el siguiente comando:

git diff

Es decir, puedes ver claramente aquí lo que agregué a nuestro archivo de texto: ¡hola mundo! Agreguemos nuestros cambios al archivo de texto y creemos una confirmación:

git add test_resource.txt
git commit -m "added hello word! to test_resource.txt"

Para ver todas las confirmaciones, escribe:

git log

Como puede ver, ahora tenemos dos confirmaciones. Agregaremos GitTest.java de la misma manera. No hay comentarios aquí, solo comandos:

git add GitTest.java
git commit -m "added GitTest.java"
git status

Trabajando con .gitignore

Claramente, solo queremos mantener el código fuente solo, y nada más, en el repositorio. Entonces, ¿qué más podría haber? Como mínimo, clases compiladas y/o archivos generados por entornos de desarrollo. Para decirle a Git que los ignore, necesitamos crear un archivo especial. Haga esto: cree un archivo llamado .gitignore en la raíz del proyecto. Cada línea en este archivo representa un patrón para ignorar. En este ejemplo, el archivo .gitignore se verá así:

```
*.class
target/
*.iml
.idea/
```

Vamos a ver:

• La primera línea es ignorar todos los archivos con la extensión .class
• La segunda línea es ignorar la carpeta "objetivo" y todo lo que contiene
• La tercera línea es ignorar todos los archivos con la extensión .iml
• La cuarta línea es ignorar la carpeta .idea

Intentemos usar un ejemplo. Para ver cómo funciona, agreguemos el GitTest.class compilado al proyecto y verifiquemos el estado del proyecto:

git status

Claramente, no queremos agregar accidentalmente la clase compilada al proyecto (usando git add -A). Para hacer esto, cree un archivo .gitignore y agregue todo lo que se describió anteriormente: Ahora usemos una confirmación para agregar el archivo .gitignore al proyecto:

git add .gitignore
git commit -m "added .gitignore file"

Y ahora el momento de la verdad: tenemos una clase compilada GitTest.class que está "sin seguimiento", que no queríamos agregar al repositorio de Git. Ahora deberíamos ver los efectos del archivo .gitignore:

git status

¡Perfecto! .gitignore +1 :)

Trabajando con ramas y tal

Naturalmente, trabajar en una sola rama es un inconveniente para los desarrolladores solitarios y es imposible cuando hay más de una persona en un equipo. Por eso tenemos sucursales. Como dije antes, una rama es solo un puntero móvil para confirmaciones. En esta parte, exploraremos cómo trabajar en diferentes ramas: cómo fusionar cambios de una rama a otra, qué conflictos pueden surgir y mucho más. Para ver una lista de todas las sucursales en el repositorio y comprender en cuál se encuentra, debe escribir:

git branch -a

Puede ver que solo tenemos una rama maestra. El asterisco delante de él indica que estamos en él. Por cierto, también puede usar el comando "git status" para averiguar en qué rama estamos. Luego, hay varias opciones para crear ramas (puede haber más, estas son las que uso):

• crear una nueva sucursal basada en la que estamos (99% de los casos)
• crear una rama basada en una confirmación específica (1% de los casos)

Vamos a crear una rama basada en una confirmación específica

Confiaremos en el identificador único de la confirmación. Para encontrarlo, escribimos:

git log

He resaltado la confirmación con el comentario "agregado hola mundo..." Su identificador único es 6c44e53d06228f888f2f454d3cb8c1c976dd73f8. Quiero crear una rama de "desarrollo" que comience desde este compromiso. Para ello, escribo:

git checkout -b development 6c44e53d06228f888f2f454d3cb8c1c976dd73f8

Se crea una rama con solo las dos primeras confirmaciones de la rama principal. Para verificar esto, primero nos aseguramos de cambiar a una rama diferente y observamos la cantidad de confirmaciones allí:

git status
git log

Y como era de esperar, tenemos dos confirmaciones. Por cierto, aquí hay un punto interesante: todavía no hay un archivo .gitignore en esta rama, por lo que nuestro archivo compilado (GitTest.class) ahora está resaltado con el estado "sin seguimiento". Ahora podemos revisar nuestras sucursales nuevamente escribiendo esto:

git branch -a

Puede ver que hay dos ramas: "maestro" y "desarrollo". Actualmente estamos en desarrollo.

Vamos a crear una rama basada en la actual

La segunda forma de crear una rama es crearla a partir de otra. Quiero crear una rama basada en la rama maestra. Primero, necesito cambiarlo, y el siguiente paso es crear uno nuevo. Vamos a ver:

• git checkout master: cambie a la rama maestra
• estado de git: verifica que realmente estamos en la rama principal

Aquí puede ver que cambiamos a la rama principal, el archivo .gitignore está en vigor y la clase compilada ya no está resaltada como "sin seguimiento". Ahora creamos una nueva rama basada en la rama maestra:

git checkout -b feature/update-txt-files

Si no está seguro de si esta rama es lo mismo que "maestro", puede verificarlo fácilmente ejecutando "git log" y observando todas las confirmaciones. Debería haber cuatro de ellos.

La resolución de conflictos

Antes de explorar qué es un conflicto, debemos hablar sobre fusionar una rama con otra. Esta imagen muestra el proceso de fusionar una rama con otra: Aquí tenemos una rama principal. En algún momento, se crea una rama secundaria a partir de la rama principal y luego se modifica. Una vez que el trabajo está hecho, necesitamos fusionar una rama con la otra. No describiré las diversas características: en este artículo, solo quiero transmitir una comprensión general. Si necesita los detalles, puede buscarlos usted mismo. En nuestro ejemplo, creamos la rama función/actualizar-archivos-txt. Como lo indica el nombre de la sucursal, estamos actualizando el texto. Ahora necesitamos crear una nueva confirmación para este trabajo:

git add *.txt 
git commit -m "updated txt files"
git log

Ahora, si queremos fusionar la rama función/actualizar-txt-archivos en maestro, debemos ir a maestro y escribir "git merge función/actualizar-txt-archivos":

git checkout master
git merge feature/update-txt-files
git log

Como resultado, la rama maestra ahora también incluye la confirmación que se agregó a los archivos de característica/actualización-txt. Se agregó esta funcionalidad, por lo que puede eliminar una rama de función. Para ello, escribimos:

git branch -D feature/update-txt-files

Todo está claro hasta ahora, ¿sí? Compliquemos la situación: ahora digamos que necesita cambiar el archivo txt nuevamente. Pero ahora este archivo también se cambiará en la rama maestra. En otras palabras, cambiará en paralelo. Git no podrá averiguar qué hacer cuando queramos fusionar nuestro nuevo código en la rama maestra. ¡Vamos! Crearemos una nueva rama basada en el maestro, haremos cambios en text_resource.txt y crearemos una confirmación para este trabajo:

git checkout -b feature/add-header
... we make changes to the file

git add *.txt
git commit -m "added header to txt"

Vaya a la rama maestra y también actualice este archivo de texto en la misma línea que en la rama de funciones:

git checkout master
… we updated test_resource.txt

git add test_resource.txt
git commit -m "added master header to txt"

Y ahora el punto más interesante: necesitamos fusionar los cambios de la rama característica/agregar encabezado a maestro. Estamos en la rama maestra, por lo que solo necesitamos escribir:

git merge feature/add-header

Pero el resultado será un conflicto en el archivo test_resource.txt: Aquí podemos ver que Git no pudo decidir por sí solo cómo fusionar este código. Nos dice que primero debemos resolver el conflicto y solo luego realizar el compromiso. DE ACUERDO. Abrimos el archivo con el conflicto en un editor de texto y vemos: Para comprender lo que hizo Git aquí, debemos recordar qué cambios hicimos y dónde, y luego comparar:

1. Los cambios que estaban en esta línea en la rama maestra se encuentran entre "<<<<<<< HEAD" y "=======".
2. Los cambios que estaban en la rama característica/agregar encabezado se encuentran entre "=======" y ">>>>>>> característica/agregar encabezado".

Así es como Git nos dice que no pudo averiguar cómo realizar la fusión en esta ubicación del archivo. Dividió esta sección en dos partes de las diferentes ramas y nos invita a resolver el conflicto de fusión nosotros mismos. Me parece bien. Audazmente decido eliminar todo, dejando solo la palabra "encabezado": Veamos el estado de los cambios. La descripción será ligeramente diferente. En lugar de un estado "modificado", tenemos "no fusionado". Entonces, ¿podríamos haber mencionado un quinto estado? No creo que esto sea necesario. Vamos a ver:

git status

Podemos convencernos de que este es un caso especial, inusual. Continuemos:

git add *.txt

Puede notar que la descripción sugiere escribir solo "git commit". Intentemos escribir eso:

git commit

Y así lo hicimos, resolvimos el conflicto en la consola. Por supuesto, esto se puede hacer un poco más fácil en entornos de desarrollo integrado. Por ejemplo, en IntelliJ IDEA, todo está tan bien configurado que puede realizar todas las acciones necesarias dentro de él. Pero los IDE hacen muchas cosas "bajo el capó" y, a menudo, no entendemos qué está sucediendo exactamente allí. Y cuando no hay comprensión, pueden surgir problemas.

Trabajando con repositorios remotos

El último paso es descubrir algunos comandos más que se necesitan para trabajar con el repositorio remoto. Como dije, un repositorio remoto es un lugar donde se almacena el repositorio y desde el cual puedes clonarlo. ¿Qué tipo de repositorios remotos existen? Ejemplos:

• GitHub es la mayor plataforma de almacenamiento para repositorios y desarrollo colaborativo. Ya lo he descrito en artículos anteriores.
  Sígueme en GitHub . A menudo muestro mi trabajo allí en aquellas áreas que estoy estudiando para trabajar.

• GitLab es una herramienta basada en web para el ciclo de vida de DevOps con código abierto . Es un sistema basado en Git para administrar repositorios de código con su propio wiki, sistema de seguimiento de errores , canalización de CI/CD y otras funciones.
  Tras la noticia de que Microsoft compró GitHub, algunos desarrolladores duplicaron sus proyectos en GitLab.

• BitBucket es un servicio web para alojamiento de proyectos y desarrollo colaborativo basado en los sistemas de control de versiones Mercurial y Git. Hubo un tiempo en que tenía una gran ventaja sobre GitHub, ya que ofrecía repositorios privados gratuitos. El año pasado, GitHub también presentó esta capacidad para todos de forma gratuita.

• Etcétera…

Cuando trabaje con un repositorio remoto, lo primero que debe hacer es clonar el proyecto en su repositorio local. Para esto, exporté el proyecto que hicimos localmente, y ahora todos pueden clonarlo por sí mismos escribiendo:

git clone https://github.com/romankh3/git-demo

Ahora hay una copia local completa del proyecto. Para asegurarse de que la copia local del proyecto sea la más reciente, debe extraer el proyecto escribiendo:

git pull

En nuestro caso, nada en el repositorio remoto ha cambiado en la actualidad, por lo que la respuesta es: Ya está actualizado. Pero si realizo algún cambio en el repositorio remoto, el local se actualiza después de extraerlos. Y finalmente, el último comando es enviar los datos al repositorio remoto. Cuando hemos hecho algo localmente y queremos enviarlo al repositorio remoto, primero debemos crear un nuevo commit localmente. Para demostrar esto, agreguemos algo más a nuestro archivo de texto: ahora algo bastante común para nosotros: creamos una confirmación para este trabajo:

git add test_resource.txt
git commit -m "prepared txt for pushing"

El comando para enviar esto al repositorio remoto es:

git push

Bueno, eso es todo lo que quería decir. Gracias por tu atención. Sígueme en GitHub , donde publico varios proyectos de ejemplo geniales relacionados con mi estudio y trabajo personal.

Enlace útil

• Documentación oficial de Git . Lo recomiendo como referencia.