Comprender Git (parte 1) — Explícalo como si tuviera cinco años

Un confuso lío de ramas. Foto de Brandon Green .

→ Entendiendo Git (parte 1) — Explícalo como si fuera cinco Entendiendo Git (parte 2) — Contribuyendo a un equipo Entendiendo Git (parte 3) — Resolviendo conflictos (¡estén atentos!)

Git es una herramienta poderosa, pero tiene la reputación de desconcertar a los recién llegados. No ayuda que la mayoría de las personas simplemente sean arrojadas al fondo y se espere que naden.

Con el conocimiento adecuado, cualquiera puede dominar git. Una vez que empieces a entenderlo, la terminología tendrá más sentido y (eventualmente) aprenderás a amarlo. Mantente fuerte 🙏

¿Por qué otra guía?

Ya existen muchos "tutoriales de git", pero la mayoría de ellos simplemente le dicen que copie y pegue cosas específicas para realizar tareas únicas. Cualquiera que tenga un teclado puede copiar/pegar; para comprender realmente cómo funciona git y qué puede hacer por usted, necesita una comprensión un poco más profunda.

También tienden a arrojarte vocabulario sin explicar lo que realmente significan las palabras.

Esta guía tiene como objetivo brindarle una comprensión viable de las frases y comandos básicos que usará con frecuencia. Es imposible aprender una herramienta tan poderosa y compleja en una sola sesión, así que te animo a que te tomes tu tiempo y disfrutes el viaje.

¿Qué es git?

En primer lugar, GitHub no es git. Mucha gente comprensiblemente confunde los dos. GitHub es un sitio web para albergar proyectos que usan git.

Git es un tipo de sistema de control de versiones (VCS) que facilita el seguimiento de los cambios en los archivos. Por ejemplo, cuando editas un archivo, git puede ayudarte a determinar exactamente qué cambió, quién lo cambió y por qué .

Es útil para coordinar el trabajo entre varias personas en un proyecto y para realizar un seguimiento del progreso a lo largo del tiempo al guardar "puntos de control". Puede usarlo mientras escribe un ensayo o para realizar un seguimiento de los cambios en las ilustraciones y los archivos de diseño.

Git no es el único sistema de control de versiones que existe, pero es, con mucho, el más popular. Muchos desarrolladores de software usan git a diario, y entender cómo usarlo puede darle un gran impulso a su currículum.

En proyectos complejos, donde varias personas pueden realizar cambios en los mismos archivos simultáneamente, es fácil entrar en un estado extraño. Cualquiera que haya lidiado con "conflictos de combinación" y esos símbolos desconcertantes >>>>>>> ======= <<<<<<< pueden atestiguar esto.

Si comienza a comprender cómo funciona git, verá por qué ocurren los conflictos y cómo recuperarse fácilmente de estas situaciones.

como obtener git

Git viene instalado por defecto en muchos sistemas. Si aún no lo tienes:

• Puede descargar la interfaz de línea de comandos (CLI) de git aquí . Lo recomendé tanto para principiantes como para usuarios avanzados.
• Si prefiere usar una elegante interfaz gráfica de usuario (GUI), pruebe GitHub Desktop (para Windows y Mac). Esto será más simple de usar, pero hará que sea más difícil ver realmente lo que está pasando.

Todos los ejemplos a continuación asumen que está utilizando la CLI.

ℹ️ Usas la interfaz de línea de comandos escribiendo en una terminal . Si no está familiarizado con las terminales, está bien; intente esto primero (o busque ayuda en Google).

Comandos comunes

A continuación se muestra una serie de comandos básicos con descripciones de lo que hace cada uno. Esta sección pretende ser interactiva. Mientras lee, siéntase libre de probar los comandos usted mismo antes de continuar. Al final también habrá un ejemplo de la "vida real" con una lista de comandos que puede probar todos a la vez.

Notas:

• Cualquier jerga se resaltará en negrita la primera vez que se describa. Siéntase libre de buscar esos términos en el glosario oficial de git o en la guía de referencia para obtener más detalles.
• Esta es una guía simplificada. Intenta ser lo más preciso posible mientras evita algunos de los detalles más complicados. Hay enlaces al final para más profundidad.
• ✨ Habrá algunas ideas nuevas en las descripciones, así que asegúrate de seguir leyendo.

Estos son algunos de los comandos más comunes, aproximadamente en el orden en que los encontrará:

Inicie su propio repositorio desde cero (en cualquier carpeta existente en su computadora):

iniciar git

Esto creará una carpeta .git oculta dentro de su carpeta actual: este es el "repositorio" (o repositorio ) donde git almacena todos sus datos de seguimiento internos. Ahora será posible realizar un seguimiento de cualquier cambio que realice en cualquier archivo dentro de la carpeta original.

✨ La carpeta original ahora se conoce como su directorio de trabajo , a diferencia del repositorio (la carpeta .git ) que rastrea sus cambios. Trabajas en el directorio de trabajo. ¡Simple!

Clonar un repositorio existente:

clon de git https://github.com/cooperka/emoji-commit-messages.git

Esto descargará un repositorio .git de Internet (GitHub) a su computadora y extraerá la última instantánea del repositorio (todos los archivos) a su directorio de trabajo. De forma predeterminada, todo se guardará en una carpeta con el mismo nombre que el repositorio (en este caso emoji-commit-messages ).

✨ La URL que especifica aquí se denomina origen remoto (el lugar desde donde se descargaron los archivos _origin_ally). Este término se utilizará más adelante.

Ver el estado actual de su proyecto:

estado de Git

Esto imprimirá información básica, como qué archivos se han modificado recientemente.

Debe verificar su estado cada vez que esté confundido. Git imprimirá información adicional según lo que esté sucediendo actualmente para ayudarte.

Cree un nuevo nombre de sucursal :

rama git <nuevo-nombre-de-la-rama>

Puede pensar en esto como crear un "punto de control" local (técnicamente llamado referencia ) y darle un nombre. Es similar a hacer Archivo > Guardar como… en un editor de texto; la nueva rama que se crea es una referencia al estado actual de su repositorio. El nombre de la rama se puede usar en varios otros comandos, como verá pronto.

De manera similar a la bifurcación, más comúnmente guardará cada punto de control a medida que avanza en forma de confirmaciones (vea git commit a continuación más adelante).

Las confirmaciones son un tipo particular de punto de control llamado revisión . El nombre será un hash de números y letras de aspecto aleatorio, como e093542 . Este hash se puede usar en varios otros comandos, al igual que los nombres de las sucursales.

✨ Esa es realmente la función central de git: guardar puntos de control (revisiones) y compartirlos con otras personas. Todo gira en torno a este concepto.

Si alguna vez ha creado un punto de control para algo, podrá volver a él más tarde siempre que su carpeta .git esté intacta. Es mágico. Consulte [git reflog](https://git-scm.com/docs/git-reflog) si está interesado en obtener más información.

La ramificación es un tema enorme y complejo. Escribiré más sobre esto pronto; por ahora puedes leer más aquí si quieres.

Echa un vistazo a una sucursal en particular:

git checkout <nombre-de-sucursal-existente>

Puede pensar en esto como "reanudar" desde un punto de control existente. Todos sus archivos se restablecerán al estado en el que se encontraban en esa rama en particular.

⚠️ Tenga en cuenta que cualquier cambio en su directorio de trabajo se mantendrá. Consulte [git stash](https://git-scm.com/docs/git-stash) si está interesado en una forma sencilla de evitar dolores de cabeza.

😎 Puede usar el indicador -b como acceso directo para crear una nueva rama y luego comprobarlo todo en un solo paso. Esto es bastante común:

git checkout -b <nuevo-nombre-de-sucursal>

Ver las diferencias entre los puntos de control:

git diff <nombre-de-sucursal> <nombre-de-otra-sucursal>

Después de editar algunos archivos, simplemente puede escribir git diff para ver una lista de los cambios que ha realizado. Esta es una buena manera de verificar dos veces su trabajo antes de confirmarlo.

Para cada grupo de cambios, verá el aspecto que solía tener el archivo (con el prefijo - y de color rojo), seguido de cómo se ve ahora (con el prefijo + y de color verde).

Consulte más abajo para obtener ejemplos más avanzados de este comando.

Organice sus cambios para prepararse para confirmarlos:

git agregar <archivos>

Después de editar algunos archivos, este comando marcará cualquier cambio que haya realizado como "preparado" (o "listo para confirmar").

⚠️ Si luego va y realiza más cambios, esos nuevos cambios no se organizarán automáticamente, incluso si ha cambiado los mismos archivos que antes. Esto es útil para controlar exactamente lo que comete, pero también es una gran fuente de confusión para los recién llegados.

Si alguna vez no está seguro, simplemente escriba git status nuevamente para ver qué está pasando. Verá "Cambios por confirmar:" seguido de los nombres de los archivos en verde. Debajo verá "Cambios no preparados para la confirmación:" seguido de los nombres de los archivos en rojo. Estos aún no están escenificados.

😎 Como atajo, puede usar comodines como con cualquier otro comando de terminal. Por ejemplo:

git agregar README.md app/*.txt

Esto agregará el archivo README.md , así como todos los archivos en la carpeta de la app que terminen en .txt . Por lo general, solo puede escribir git add --all para agregar todo lo que ha cambiado.

Confirme sus cambios por etapas:

git cometer

Esto abrirá su editor de texto de línea de comandos predeterminado y le pedirá que escriba un mensaje de confirmación . Tan pronto como guarde y salga, su confirmación se guardará localmente.

El mensaje de confirmación es importante para ayudar a otras personas a comprender qué se cambió y por qué lo cambió. Hay una breve guía aquí que explica cómo escribir mensajes de confirmación útiles.

😎 Puede usar la marca -m como acceso directo para escribir un mensaje. Por ejemplo:

git commit -m "Agregar una nueva característica"

Empuje su rama para cargarlo en otro lugar:

git push origin <nombre-de-sucursal>

Esto cargará su sucursal en el remoto llamado **origin** (recuerde, esa es la URL definida inicialmente durante la clone ).

Después de un push exitoso, sus compañeros de equipo podrán pull su rama para ver sus confirmaciones (consulte git pull continuación).

😎 Como atajo, puede escribir la palabra HEAD en lugar de branch-name para usar automáticamente la rama en la que se encuentra actualmente. HEAD siempre se refiere a su último punto de control, es decir, la última confirmación en su rama actual.

✨ Como se mencionó anteriormente, todo en git se puede considerar como un punto de control. Aquí hay una lista de los tipos de puntos de control que conoce ahora (nuevamente, estos se denominan técnicamente "referencias" y "revisiones"):

• HEAD
• <branch-name> , por ejemplo, master
• <commit-hash> , por ejemplo, e093542d01d11c917c316bfaffd6c4e5633aba58 (o e093542 para abreviar)

También hay:

• <tag-name> , por ejemplo, v1.0.0
• stash

Finalmente, los caracteres especiales como ^ , ~ y @{} se pueden usar para modificar las referencias. Son bastante útiles; Obtenga más información aquí .

Obtener la información más reciente sobre un repositorio:

buscar

Esto descargará la información más reciente sobre el repositorio desde el origin (como todas las diferentes sucursales almacenadas en GitHub).

No cambia ninguno de sus archivos locales, solo actualiza los datos de seguimiento almacenados en la carpeta .git .

Fusionar cambios de otra persona:

git merge <otro-nombre-de-la-rama>

Esto tomará todas las confirmaciones que existen en la other-branch-name y las integrará en su propia rama actual.

⚠️ Esto utiliza cualquier dato de rama almacenado localmente, así que asegúrese de haber ejecutado git fetch primero para descargar la información más reciente.

Por ejemplo, si alguien más agrega algunas confirmaciones a la rama master de origin , puede hacer lo siguiente para descargar sus cambios y actualizar su propia rama master local:

git checkout master # Asegúrate de estar en la rama correcta.

✨ El nombre origin/master aquí literalmente significa el punto de control de origin/master en su computadora. Git usa esta notación para diferenciar ramas del mismo nombre (p. ej., master ) ubicadas en diferentes lugares (p. ej., sus propias sucursales frente a las sucursales de origin ).

😎 Como atajo, puede usar el comando de extracción para buscar y fusionar todo en un solo paso. Esto es más común que fusionar manualmente como arriba:

maestro de origen git pull

Aquí separamos las palabras origin y master (sin una barra como arriba). No queremos usar el punto de control de origin/master en nuestra propia computadora, porque está almacenado sin conexión y probablemente esté desactualizado. En su lugar, queremos buscar directamente desde la rama master del punto final remoto llamado origin . Estar atento; la diferencia es importante!

Para una comprensión más profunda de cómo funciona la fusión y cómo se resuelven los conflictos (con imágenes y gráficos divertidos), consulte los documentos oficiales de fusión . Esto también se cubrirá extensamente en la parte 3 de esta serie.

ejemplo de la vida real

Aquí hay una serie de comandos que hipotéticamente podrían ejecutarse mientras se desarrolla una característica real. Vea si puede averiguar qué haría cada uno, luego pruébelo usted mismo y compruébelo.

git clone https://github.com/cooperka/emoji-commit-messages.gitcd emoji-commit-messagesgit statusgit checkout -b my-new-featureecho "Este es un nuevo archivo genial" > my-file.txtgit statusgit add - -allgit statusgit diff HEADgit commit -m “Agregar mi-archivo.txt”git statusgit loggit push origin HEADgit checkout mastergit pull

La mayoría de estos comandos tienen parámetros adicionales que puede pasar para personalizarlos y versiones abreviadas para abreviar, todo lo cual hace que todo sea más interesante (léase: confuso). Por lo general, hay más de una forma de realizar una tarea determinada.

¿Ahora que?

¡Ahora sabes todo lo que hay que saber sobre git!

…es broma, esto es solo la punta del iceberg. Hay mucho más que debe comprender antes de poder afirmar que es un experto, pero por ahora, al menos tiene los conceptos básicos para poder trabajar con un equipo y comprender la jerga.

Una vez que comprenda estos comandos básicos, puede y debe continuar aprendiendo más en el sitio web de git o en esta guía más avanzada .

Si encuentra esto útil, ayúdenos tocando el botón 👏 tantas veces como desee para que otros también puedan encontrarlo.

Gracias, y estén atentos a la segunda parte . Déjame saber en los comentarios si hay algún tema específico que te interese.