En nuestros tutoriales anteriores para el software de control de versiones git, aprendimos los comandos básicos esenciales para usar git, como así como cómo trabajar con Github.com para establecer un repositorio y enviar el código de nuestro proyecto al sitio web.
Ahora es el momento de comenzar a trabajar con GitHub (y git) de la forma en que deben ser utilizado: hacer cambios en el proyecto de forma segura a un lado y fusionarlos de nuevo en el proyecto original una vez que hayan demostrado ser correctos O al menos no desastroso.
A estas alturas, ya comprende que git guarda cada versión de su proyecto como una instantánea del código exactamente como estaba en el momento en que lo comprometió. Básicamente, crear una línea de tiempo de las versiones de un proyecto a medida que avanza, de modo que pueda volver a una versión anterior en caso de que ocurra un desastre.
La forma en que git y GitHub administran esta línea de tiempo, especialmente cuando hay más de una persona que esté trabajando en el proyecto y realizando cambios, es mediante el uso de sucursales. Una rama es esencialmente un conjunto único de cambios de código con un nombre único. Cada repositorio puede tener una o más ramas. La rama principal: aquella en la que todos los cambios finalmente se fusionan y se llama maestra. Esta es la versión de trabajo oficial de su proyecto, y la que ve cuando visita el repositorio del proyecto en github.com/yourname/projectname.
No se meta con el maestro. Si realiza cambios en la rama principal de un proyecto grupal mientras otras personas también están trabajando en él, sus cambios sobre la marcha se extenderán para afectar a todos los demás y muy rápidamente habrá conflictos de fusión, llanto, desgarro de prendas, y plagas de langostas. Es así de serio.
¿Por qué es tan importante no meterse con el maestro? Una palabra: la rama maestra se puede implementar. Es su código de producción, listo para lanzarse al mundo. La rama maestra está destinada a ser estable, y es el contrato social del software de código abierto para nunca, nunca empujar nada para dominar que no esté probado o que rompa la compilación. La única razón por la que GitHub funciona es que siempre es seguro trabajar desde el maestro.
Bifurcación
En cambio, todos usan ramas creadas desde el maestro para experimentar, hacer ediciones, adiciones y cambios , antes de eventualmente revertir esa rama en el maestro una vez que hayan sido aprobados y se sepa que funcionan. Master luego se actualiza para contener todas las cosas nuevas.
Para comenzar a trabajar en algo nuevo en un proyecto, o para cambiar cosas existentes, crea una rama fuera de la rama master estable. Sigamos trabajando con el proyecto de muestra creado para nuestro tutorial anterior, buen viejo studious_octo_carnival. Ahora abra su versión en su computadora y acceda al directorio.
Paso 1: Haga un inventario.
Antes de crear nuevas sucursales, queremos verificar si existen otras sucursales. . Sabemos sobre el maestro, pero ¿quién sabe qué estarán haciendo nuestros colaboradores del proyecto, esos traviesos monos? Entonces podemos ver todas las ramas existentes escribiendo «git branch -a» en la terminal, lo que le dice a git que queremos ver TODAS las ramas en este proyecto, incluso aquellas que no están en nuestro espacio de trabajo local.
Esto devuelve la salida que ves en el ejemplo de código a continuación. Su apariencia puede variar un poco según tu sistema operativo y la aplicación de terminal, pero la información es la misma en última instancia. El asterisco junto a «maestro» en la primera línea de la salida indica que estamos actualmente en esa rama. La segunda línea nos dice que en nuestro origen remoto con nombre, hay una sola rama, también llamada maestra. (Recuerde que nuestro control remoto es el repositorio de GitHub para este proyecto).
Paso 2: Cree una nueva rama
Ahora que sabemos cómo ver las ramas, ¡hagamos una! Tenga en cuenta a medida que avanzamos que tenemos nuestra rama maestra, nuestro proyecto original. Ahora vamos a crear una nueva versión del proyecto, una rama, para jugar y hacer cambios localmente en nuestra computadora, mientras que la versión original del proyecto, la maestra, permanece sin ser molestada allí en GitHub. Le damos a la nueva rama un nombre descriptivo para recordarnos lo que pretendemos hacer mientras trabajamos en ella. En este caso, será un simple «Hola mundo», así que llamémoslo hello_octo.
Para crear esta nueva rama, escriba «git checkout -b branchNameHere» (entonces, en nuestro caso, «git checkout -b hello_octo”).
Suponiendo que nadie más haya creado una rama llamada «hello_octo», git devuelve «Cambiado a una nueva rama ‘hello_octo'». (En el caso de que ya exista una rama con ese nombre, git nos diría en su lugar «fatal: una rama llamada ‘hello_octo’ ya existe». No es gran cosa, simplemente haz git checkout -b de nuevo con una nueva variación de nombre).
También podemos usar el comando git checkout para alternar entre nuestras dos ramas. Escriba «git checkout branchName» para cambiar a esa rama.Entonces, «git checkout master» te lleva a master mientras que «git checkout hello_octo» te lleva de regreso a la rama hello_octo.
Si intentas cambiar a una rama que no existe, como «git checkout hello_kitty», git te hará saber que no es posible:
¿Cómo sabe git en qué rama estás actualmente? Git siempre está mirando lo que haces y mantiene un puntero especial llamado HEAD. Como la aguja de una brújula siempre apunta hacia el norte, HEAD siempre indica el rama local en la que estás actualmente.
(También podríamos haber creado nuestra rama usando el comando git «git branch branchNameHere», y luego cambiar a ella con git checkout. Sin embargo, el pequeño atajo con el «-b» en «git checkout -b branchNameHere» crea la rama Y cambia a ella. No puedo decirte cuántos codificadores nuevos en git generan mensajes de error y frustración porque simplemente no se han acordado de cambiar a su nueva rama después de crear yo t. Por lo tanto, nos quedamos con git checkout -b, mmmkay?)
Haciendo cambios en nuestra rama de trabajo
Ahora que tenemos varias ramas, nuestra rama de trabajo para realizar cambios, y nuestra rama maestra permanece sin ser molestada – podemos ponernos a trabajar. En nuestro escenario, usaremos nuestra rama «hello_octo» para realizar y probar nuestros cambios, y luego los enviaremos a la rama maestra en GitHub.
Recuerde asegurarse de estar en su rama de trabajo, y no maestra, con la vieja rama git -a.
Paso 3. Cree un nuevo archivo en blanco, llamado «hello_octo_world»:
(Este archivo en blanco es solo para fines de demostración, por lo que no se preocupe de que no haya un nombre / tipo de extensión de archivo).
Ya que es nuevo, correcto ahora este archivo está solo en su rama. Use el comando «ls» para verlo:
Sin embargo, recuerde que estamos en nuestra rama de trabajo, hello_octo, donde Creamos esta cosa nueva. El maestro no sabe nada sobre no hello_octo, porque está aislado de manera segura de cualquier cambio que estemos haciendo aquí en la rama de trabajo. Sigue siendo el mismo maestro serenamente sin cambios con el que comenzamos:
Paso 4: Preparar y enviar nuestro nuevo archivo a la rama de trabajo.
Ahora es el momento para preparar (agregar) y enviar nuestro nuevo archivo en la rama de trabajo. (¿Te suena familiar?). Esto adjuntará esta nueva entidad a la rama de trabajo en preparación para eventualmente moverla a master. Este archivo ahora existe en la rama hello_octo; como vimos anteriormente, no existe actualmente en la rama maestra.
En este punto, acaba de tomar un instantánea de los cambios en la sucursal. En un proyecto del mundo real, es probable que haya más cambios y trabajo para acabar. Ahora es cuando harías esto, haciendo confirmaciones en el camino en puntos lógicos. Recuerda que, en GitHub, las confirmaciones representan tus guardados consecutivos. Cada confirmación tiene un mensaje de confirmación asociado, que es una descripción que explica específicamente qué hizo allí y por qué. Los mensajes de confirmación capturan el historial de sus cambios, para que en el futuro usted, así como otros colaboradores del proyecto, puedan comprender lo que ha hecho y por qué.
Fusionar código entre ramas
Una vez que finalmente terminaron con todos los cambios y adiciones, y todo funciona *, es hora de fusionar. La parte interesante viene después de que volvemos a nuestra rama maestra (que, ¡dilo conmigo! – hacemos con «git checkout master»). Parece que falta «Hello_octo_world», pero no lo es, actualmente, existe en nuestro trabajo. rama y estamos en nuestra rama principal. Te muestro esto de nuevo porque está en el corazón de la comprensión de las ramas en git:
Ahora: en este ejercicio , «hello_octo_world» representa cualquier cambio en cualquier archivo (o la adición de un archivo completamente nuevo) que haya pasado todas las pruebas en nuestra rama de desarrollo y esté listo para estar en producción. El proceso de mover código entre ramas (a menudo desde el desarrollo a producción) se conoce como fusión.
Muy importante: al fusionar, necesitamos estar en la rama a la que queremos fusionar. Básicamente, le diremos a git: «¿Ves esa cosa nueva? Está bien traerlo aquí ahora. ”
Paso 5: Fusionar los cambios de la rama de trabajo
En este caso, ya que queremos fusionar desde nuestra rama de trabajo, donde el» hello_octo_world » archivo existe, a nuestra rama maestra, necesitamos estar en la rama maestra.
Una vez en la rama maestra, todo lo que tenemos que hacer es ejecutar el comando de fusión. La mejor manera de hacerlo es escribir » git merge –no-ff ”- el» –no-ff «adicional le dice a git que queremos retener todos los mensajes de confirmación antes de la fusión. Esto facilitará el seguimiento de los cambios en el futuro:
Volviendo a GitHub
Lo último que tenemos que hacer ahora es hacerle saber a GitHub que hemos estado jugando con dominar aquí en nuestro entorno de desarrollo local.
En otras palabras, es hora de git push. ¡Tienes esto!
La salida de git confirma que la fusión de tu rama de desarrollo a la rama maestra en tu entorno local, ahora se ha copiado en el servidor remoto: «maestro → maestro».
¡Y eso es todo! Creamos con éxito una rama de trabajo separada de la maestra. Le hicimos cambios. Organizamos y comprometimos esos cambios. Luego los fusionamos de nuevo al maestro en nuestro entorno de trabajo local. Luego, finalmente, subí todo a GitHub para que todas las versiones de nuestro proyecto sean iguales, en todas partes.
Una nota final
Un poco de limpieza está en orden ahora: dado que hemos combinado con éxito nuestra rama hello_octo, ya no la necesitamos. Para eliminar una rama combinada, simplemente escriba «git branch -d branchName»:
No se preocupe: si accidentalmente intenta eliminar una rama que aún no se ha fusionado, git arrojará un error.
¡Entonces! Hasta ahora hemos estado usando un proyecto de muestra extremadamente simplificado, porque en este punto lo más importante es comprender y asimilar el flujo de trabajo de git. Hay mucho más en la fusión que esto en el mundo real; por ejemplo, ¿qué sucede si recibe mensajes de error porque su fusión tiene conflictos? No te preocupes, nuevo git-ster, llegaremos allí.
Tu tarea: crea («toca») algunos archivos nuevos más en el proyecto de ejemplo y practica haciendo cambios, preparando, confirmando y finalmente fusionándolos Tenga cuidado de entender hacia dónde apunta su HEAD, es decir, cuál es su rama actual. Solo haga cambios en su rama de trabajo.
Porque recuerde: No. Ensucie. Con. El. Maestro .