En lugar de una introducción
Hola futuro ingeniero de software senior.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 de gestión del trabajo. Necesario para realizar un seguimiento de los cambios que se producen a lo largo del tiempo. Es decir, paso a paso vemos qué archivos han cambiado y cómo. Esto es especialmente importante cuando analizas lo que se hizo dentro de una tarea: esto hace posible retroceder. Imaginemos una situación: había un código que funcionaba, todo estaba bien en él, pero decidimos mejorar algo, modificarlo aquí, modificarlo allá. Todo estaba bien, pero esta mejora rompía la mitad de la funcionalidad e imposibilitaba el trabajo. Entonces, ¿qué sigue? Sin el Gita, uno tendría que sentarse durante horas y recordar cómo era todo originalmente. Y entonces simplemente volvemos al compromiso y eso es todo. ¿O qué pasa si hay dos desarrolladores realizando cambios en el código al mismo tiempo? Sin Git se ve así: copiaron el código del original e hicieron lo que tenían que hacer. Llega el momento y ambos quieren agregar sus cambios a la carpeta principal. ¿Y qué hacer en esta situación?... Ni siquiera me atrevo a estimar el tiempo para realizar este trabajo. No habrá ningún problema de este tipo si usas Git.Instalación de Git
Instalemos Git en tu computadora. Entiendo que cada uno tiene un sistema operativo diferente, por lo que intentaré describir varios casos.Instalación para Windows
Como de costumbre, debe descargar el archivo exe y ejecutarlo. Aquí todo es sencillo: haz clic en el primer enlace de Google , instala y listo. Para trabajar usaremos la consola bash que nos proporcionan. Para trabajar en Windows, necesita ejecutar Git Bash. Así es como se ve en el menú de inicio:
Y esta ya es una consola en la que puedes trabajar. Para no ir a la carpeta con el proyecto cada vez que abre git allí, puede hacer clic derecho en la carpeta para abrir la consola con la ruta que necesitamos: 
Instalación para Linux
Por lo general, git ya está instalado e incluido en las distribuciones de Linux, ya que es una herramienta escrita originalmente para desarrollar el kernel de Linux. Pero hay situaciones en las que no existe. Para verificar esto, debe abrir una terminal y escribir: git --version. Si hay una respuesta clara, no es necesario instalar nada. Abra una terminal e instálela. Trabajo en Ubuntu, así que puedo decirte qué escribir: sudo apt-get install git. Y listo: ahora puedes usar Git en cualquier terminal.Instalación en MacOS
Aquí también es necesario comprobar primero si Git ya existe (ver arriba, como en Linux). Si no, la forma más sencilla es descargar la última versión. Si XCode está instalado, Git definitivamente se instalará automáticamente.configuración de git
El git tiene una configuración de usuario desde la cual se realizará el trabajo. Esto es algo razonable y necesario, porque cuando se crea una confirmación, Git toma exactamente esta información para el campo Autor. Para configurar un nombre de usuario y contraseña para todos los proyectos, debe ingresar los siguientes comandos:
git config --global user.name ”Ivan Ivanov”
git config --global user.email ivan.ivanov@gmail.com
git config user.name ”Ivan Ivanov”
git config user.email ivan.ivanov@gmail.comUn poco de teoría...
Para permanecer en el tema, es recomendable agregar algunas palabras y acciones nuevas a su mensaje... De lo contrario, no habrá nada de qué hablar. Por supuesto, esto es jerga y una copia del inglés, por lo que agregaré significados en inglés. ¿Qué palabras y acciones?
- repositorio git;
- comprometerse (comprometerse);
- rama;
- unir;
- conflictos;
- jalar;
- empujar;
- cómo ignorar algunos archivos (.gitignore).
Estados en Git
El Gita tiene varios estados que es necesario comprender y recordar:- sin seguimiento;
- modificado;
- preparado (escenificado);
- comprometido.
¿Qué significa?
Estos son los estados en los que se encuentran los archivos de nuestro código. Es decir, su camino de vida suele verse así:- Un archivo que se crea y no se agrega al repositorio no tendrá seguimiento.
- Realizamos cambios en los archivos que ya se han agregado al repositorio de Git; están en estado modificado.
- De los archivos que hemos modificado, seleccionamos solo aquellos (o todos) que necesitamos (por ejemplo, no necesitamos clases compiladas), y estas clases con cambios entran en el estado preparado.
- Se crea una confirmación a partir de los archivos preparados del estado preparado y se ingresa en el repositorio de Git. Después de esto, el estado preparado está vacío. Pero la modificación aún puede contener algo.
¿Qué es un compromiso?
Una confirmación es el objeto principal en el control de versiones. Contiene todos los cambios desde esa confirmación. Las confirmaciones están vinculadas entre sí como una lista enlazada individualmente. A saber: existe la primera confirmación. Cuando se crea una segunda confirmación, (la segunda) sabe que viene después de la primera. Y de esta manera puedes rastrear la información. El commit también tiene su propia información, los llamados metadatos:- un identificador de confirmación único mediante el cual puede encontrarlo;
- el nombre del autor del compromiso que lo creó;
- fecha de creación del compromiso;
- un comentario que describe lo que se hizo durante esta confirmación.
que es una sucursal
Una rama es un puntero a una confirmación. Dado que una confirmación sabe qué confirmación vino antes que ella, cuando una rama apunta a una confirmación, todas las anteriores también se refieren a ella. En base a esto, podemos decir que puede haber tantas ramas 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 nueva.
Empezando con Git
Puedes trabajar sólo con un repositorio local o con uno remoto. Para ejecutar los comandos necesarios, solo puede utilizar el repositorio local. Almacena toda la información solo localmente en el proyecto en la carpeta .git. Si hablamos de remoto, entonces toda la información se almacena en algún lugar de un servidor remoto: solo una copia del proyecto se almacena localmente, cuyos cambios se pueden enviar (git push) al repositorio remoto. Aquí y más discutiremos cómo trabajar con git en la consola. Por supuesto, puede utilizar algunas soluciones gráficas (por ejemplo, en Intellij IDEA), pero primero debe averiguar qué comandos están sucediendo y qué significan.Trabajar con Git en un repositorio local
A continuación, te sugiero que sigas todos los pasos que hice mientras leías el artículo. Esto mejorará su comprensión y retención del material. Así que buen provecho :) Para crear un repositorio local, debes escribir:
git init
Esto creará una carpeta .git en la ubicación donde se encuentra la consola. .git es una carpeta que almacena toda la información sobre el repositorio de Git. No es necesario eliminarlo ;) A continuación, se agregan archivos a este proyecto y su estado pasa a ser Sin seguimiento. Para ver cuál es el estado laboral actual, escriba:
git status
Estamos en la rama master, y hasta que pasemos a otra todo seguirá así. De esta manera puede ver qué archivos se han modificado pero aún no se han agregado al estado preparado. Para agregarlos al estado preparado, debes escribir git add. Puede haber varias opciones aquí, por ejemplo:
- git add -A: agrega todos los archivos desde el estado preparado;
- git agregar. — agregue todos los archivos de esta carpeta y todos los internos. Esencialmente igual que el anterior;
- git add <nombre de archivo>: agrega solo un archivo específico. Aquí puedes usar expresiones regulares para agregar según algún patrón. Por ejemplo, git add *.java: esto significa que solo necesitas agregar archivos con la extensión java.
git add *.txt
git status
A partir de esto podemos ver que la expresión regular funcionó correctamente y ahora test_resource.txt está en un estado preparado. Y finalmente, la última etapa (con un repositorio local, con uno remoto habrá uno más;)): confirmar y crear una nueva confirmación:
git commit -m “all txt files were added to the project”
A continuación, hay un excelente comando para ver el historial de confirmaciones de una rama. Usémoslo:
git log
Aquí ya puedes ver que ha aparecido nuestro primer commit con el texto que transferimos. Es muy importante comprender que el texto que aprobemos debe definir con la mayor precisión posible lo que se hizo durante esta confirmación. Esto ayudará muchas veces en el futuro. Un lector curioso que aún no se haya quedado dormido puede decir: ¿qué pasó con el archivo GitTest.java? Ahora lo descubriremos, use para esto:
git status
Como podemos ver, permanece en el estado sin seguimiento y está esperando entre bastidores. ¿O tal vez no queremos agregarlo al proyecto en absoluto? A veces ocurre. A continuación, para hacerlo más interesante, intentemos cambiar nuestro archivo de texto test_resource.txt. Agreguemos algo de texto allí y verifiquemos el estado:
git status
Aquí puede ver claramente la diferencia entre los dos estados: sin seguimiento y modificado. GitTest.java está en estado sin seguimiento y test_resource.txt está en estado modificado. Ahora que ya hay archivos en estado modificado, podemos ver los cambios que se les han realizado. Esto se puede hacer usando el comando:
git diff
Es decir, aquí puedes ver claramente que agregué ¡hola mundo! a nuestro archivo de texto. Agregue cambios al archivo de texto y confirme:
git add test_resource.txt
git commit -m “added hello word! to test_resource.txt”
git log
Como puede ver, ya hay dos confirmaciones. De la misma forma agregamos GitTest.java. Ahora no hay comentarios, sólo comandos:
git add GitTest.java
git commit -m “added GitTest.java”
git status
Trabajando con .gitignore
Está claro que sólo queremos almacenar el código fuente y nada más en el repositorio. ¿Qué más podría ser? Como mínimo, clases y/o archivos compilados que crean entornos de desarrollo. Para que Git los ignore, es necesario crear un archivo especial. Hacemos esto: creamos un archivo en la raíz del proyecto llamado .gitignore, y en este archivo cada línea será un patrón a ignorar. En este ejemplo, git ignore se vería así:
```
*.class
target/
*.iml
.idea/
```- la primera línea es ignorar todos los archivos con la extensión .class;
- la segunda línea es para ignorar la carpeta de destino 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.
git status
Claramente, no queremos agregar accidentalmente (si usamos git add -A) una clase compilada al proyecto. Para hacer esto, cree un archivo .gitignore y agregue todo lo que se describió anteriormente: 
Ahora agreguemos git ignore al proyecto con una nueva confirmación:
git add .gitignore
git commit -m “added .gitignore file”
git status
Todo está claro) Git ignora +1)
Trabajar con sucursales y similares.
Por supuesto, trabajar en una rama es un inconveniente para una e imposible cuando hay más de una persona en el equipo. Hay una sucursal para esto. Como dije antes, una rama es simplemente un puntero móvil a confirmaciones. En esta parte, veremos 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 y el asterisco delante dice que estamos en ella. Por cierto, para saber en qué rama estamos, también podemos usar la verificación de estado (git status). A continuación, hay varias opciones para crear ramas (tal vez haya más, yo uso estas):
- crear una nueva rama basada en la que estamos (99% de los casos);
- cree una rama basada en una confirmación específica (1%).
Crear una rama basada en una confirmación específica
Nos basaremos en el identificador de confirmación único. Para encontrarlo escribimos:
git log
Destaqué el compromiso con el comentario "agregué hola mundo...". Tiene un identificador único: "6c44e53d06228f888f2f454d3cb8c1c976dd73f8". Quiero crear una rama de desarrollo a partir de este compromiso. Para esto escribiré:
git checkout -b development 6c44e53d06228f888f2f454d3cb8c1c976dd73f8
git status
git log
Y es cierto: resultó que tenemos dos compromisos. Por cierto, un punto interesante: todavía no hay ningún archivo .gitignore en esta rama, por lo que nuestro archivo compilado (GitTest.class) ahora está resaltado en el estado sin seguimiento. Ahora podemos revisar nuestras ramas nuevamente escribiendo:
git branch -a
Se puede ver que hay dos ramas: maestra y desarrollo, y ahora estamos en desarrollo.
Crear una rama basada en la actual
La segunda forma de crear una rama es construir sobre otra. Quiero crear una rama basada en la rama maestra, por lo que primero debo cambiar a ella y el siguiente paso es crear una nueva. Miremos:- git checkout master - pasar a la rama master;
- git status: comprueba si está en el maestro.
Aquí puede ver que nos hemos movido a la rama maestra, git ignore ya está funcionando aquí y la clase compilada ya no aparece como sin seguimiento. Ahora creamos una nueva rama basada en la rama maestra:
git checkout -b feature/update-txt-files
Si tiene alguna duda de que esta rama no será la misma que la maestra, puede verificarlo fácilmente escribiendo git log y observando todas las confirmaciones. Debería haber cuatro de ellos.
Resolver conflictos
Antes de que entendamos qué es un conflicto, debemos hablar sobre fusionar (fusionar) una rama con otra. Esta imagen puede mostrar el proceso cuando una rama se fusiona con otra:
es decir, hay una rama principal. En algún momento, a partir de él se crea uno secundario, en el que se producen cambios. Una vez realizado el trabajo, debes fusionar una rama con otra. No describiré varias características: solo quiero transmitir comprensión en el marco de este artículo, y usted mismo descubrirá los detalles si es necesario. Entonces, en nuestro ejemplo, creamos la rama feature/update-txt-files. Como está escrito en el nombre de la sucursal, actualizaremos el texto. 
Ahora necesitas crear una nueva confirmación para este asunto:
git add *.txt
git commit -m “updated txt files”
git log
Ahora, si queremos fusionar la rama feature/update-txt-files en master, debemos ir a master y escribir git merge feature/update-txt-files:
git checkout master
git merge feature/update-txt-files
git log
Como resultado, ahora la rama maestra también tiene una confirmación que se agregó a feature/update-txt-files. Esta funcionalidad se agrega para que pueda eliminar la rama de funciones. Para ello escribimos:
git branch -D feature/update-txt-files
git checkout -b feature/add-header
... делаем изменения в файле
git add *.txt
git commit -m “added header to txt”
Vaya a la rama maestra y actualice también este archivo de texto en la misma línea que la rama de características:
git checkout master
… обновo test_resource.txt
git add test_resource.txt
git commit -m “added master header to txt”
git merge feature/add-header
Y aquí podemos ver que Git no pudo decidir de forma independiente cómo fusionar este código y dice que primero debemos resolver el conflicto y solo luego realizar una confirmación. Ok, abramos el archivo que contiene el conflicto en un editor de texto y veamos: 
Para entender lo que hizo git aquí, debes recordar lo que escribimos y comparar:
- entre “<<<<<<< HEAD” y “=======” son los cambios maestros que estaban en esta línea en la rama maestra.
- entre “=======” y “>>>>>>> característica/agregar-encabezado” hay cambios que estaban en la rama característica/agregar-encabezado.
Veamos el estado de los cambios, la descripción será ligeramente diferente. No habrá ningún estado modificado, sino Sin fusionar. Entonces podríamos agregar con seguridad un quinto estado... Pero creo que esto es innecesario, veamos:
git status
Estábamos convencidos de que se trataba de un caso diferente e inusual. Continuemos:
git add *.txt
En la descripción notarás que solo sugieren escribir git commit. Escuchamos y escribimos:
git commit
Y eso es todo: así lo hicimos: resolvimos el conflicto en la consola. Por supuesto, en entornos de desarrollo puedes hacer esto un poco más fácilmente, por ejemplo, en Intellij IDEA todo está tan bien configurado que puedes realizar todas las acciones necesarias en él. Pero el entorno de desarrollo hace muchas cosas bajo el capó y, a menudo, no entendemos qué sucedió exactamente allí. Y cuando no hay comprensión, pueden surgir problemas.
Trabajar con repositorios remotos
El último paso es comprender algunos comandos más necesarios para trabajar con un repositorio remoto. Como ya dije, un repositorio remoto es un lugar donde se almacena el repositorio y desde donde puedes clonarlo. ¿Qué tipos de repositorios remotos existen? Hay toneladas de ejemplos:-
GitHub es el repositorio más grande para repositorios y desarrollo colaborativo. Ya lo he descrito en artículos anteriores.
Suscríbete a mi cuenta de Github . A menudo expongo allí mi trabajo en las áreas que estudio durante mi trabajo. -
GitLab es una herramienta de ciclo de vida de DevOps basada en web de código abierto que proporciona un sistema de gestión de repositorio de código para Git con su propia wiki, sistema de seguimiento de problemas , proceso de CI/CD y otras características.
Tras la noticia de que Microsoft compró GitHub, algunos desarrolladores duplicaron su trabajo en GitLab. -
BitBucket es un servicio web para el alojamiento de proyectos y su desarrollo conjunto, basado en el sistema de control de versiones Mercurial y Git. Hubo un tiempo en que tenía una gran ventaja sobre GitHub porque tenía repositorios privados gratuitos. El año pasado, GitHub también puso esta función a disposición de todos de forma gratuita.
-
Etcétera…
git clone https://github.com/romankh3/git-demo
git pull
En nuestro caso, nada ha cambiado ni remotamente, por lo que la respuesta es: Ya están actualizados. Pero si hago algunos cambios en el repositorio remoto, el local se actualizará después de que los realicemos. Y finalmente, el último comando es enviar datos al repositorio remoto. Cuando hemos hecho algo localmente y queremos transferirlo a un repositorio remoto, primero debemos crear un nuevo commit localmente. Para hacer esto, agreguemos algo más a nuestro archivo de texto: 
ahora es algo común para nosotros: creamos un compromiso para este asunto:
git add test_resource.txt
git commit -m “prepated txt for pushing”
git push
Eso es todo lo que quería decirte. Gracias por su atención. Suscríbase a mi cuenta de GitHub , donde publico diferentes proyectos de ejemplo interesantes de lo que estudio y uso en el trabajo.
Enlaces útiles
- El documento oficial sobre Git está en ruso . Lo recomiendo como guía de referencia.
- git
GO TO FULL VERSION