Si escribes software para ganarte la vida en 2018, puedo decir con confianza que estás familiarizado con Git. La herramienta creada por Linus Torvalds se ha convertido en sinónimo de control de versiones. Y sin duda, una de las mejores características de Git es la forma en que elimina el dolor de ramificar y fusionar. Hay varias formas de crear una rama en Git. En esta publicación, revisaremos algunos de ellos. Luego, terminaremos con una pequeña reflexión sobre el modelo de ramificación de Git y la ramificación en general.

Creación de una rama desde el maestro

Creas ramas en Git, como era de esperar, usando el comando branch. Como muchos otros comandos Git, «branch» es muy poderoso y flexible. Además de crear ramas, también se puede usar para listarlas y eliminarlas, y puedes personalizarlas aún más. el comando empleando una amplia lista de parámetros. Comenzaremos con la primera forma de crear una rama. Supongamos que desea crear una nueva carpeta llamada «my-app», ingresarla e iniciar un nuevo repositorio de Git. Así es exactamente como lo haría:

mkdir my-appcd my-appgit init

Ahora tienes un repositorio de Git nuevo y vacío. Pero los repositorios vacíos son aburridos. Entonces, ¿qué tal si creas un nuevo archivo de rebajas con «Hello World!» escrito en él?

echo Hello World! > file.md

Si ejecuta «git status», debería ver un mensaje que dice que su archivo no tiene seguimiento:

Sin embargo, los archivos sin seguimiento tampoco son geniales, así que hagamos un seguimiento:

git add file.md

Y finalmente, creemos nuestro primera confirmación:

git commit -m "First commit"

Ahora tenemos un repositorio con una rama, que tiene exactamente una confirmación. Eso puede no sonar como el lo más emocionante del mundo (porque realmente no lo es), pero ciertamente es menos aburrido que tener un repositorio sin ningún compromiso, ¿verdad? Ahora, digamos que por alguna razón necesitas cambiar el archivo «s contenido. Pero no tengo ganas de hacer eso. ¿Qué pasa si algo sale mal y de alguna manera estropea el hermoso y prístino contenido de su archivo? (Sí, sé que es solo un archivo estúpido con «¡Hola mundo!», Pero usa los maravillosos poderes de tu imaginación y piensa en el archivo como un proxy para un proyecto mucho más complejo). La solución a este dilema es, por supuesto, crear una nueva rama:

git branch exp

Así que ahora tenemos una nueva rama llamada «exp», para experimentación Algunas personas que están acostumbradas a usar diferentes sistemas de versiones, especialmente los centralizados, podrían decir que las ramas tienen el mismo «contenido». Sin embargo, esto no es del todo exacto cuando se habla de Git. Piense en las ramas como referencias que apuntan a una confirmación determinada.

Creación de una rama a partir de una confirmación

Suponga que, por cualquier razón, renunciamos a nuestro experimento, sin agregar una sola comprometerse con la nueva rama. Volvamos al maestro y eliminemos la rama exp:

git checkout mastergit branch -d exp

Ahora que volvemos a una sola rama, agreguemos algunos compromisos, para simular el trabajo que se está realizando:

Imagina que después de hacer todo este «trabajo», aprendes que, por cualquier razón, necesitas volver en el tiempo a cuando eran solo dos líneas en el archivo y crear nuevos cambios a partir de ese momento. Pero al mismo tiempo, debes conservar el progreso que ya hiciste. En otras palabras, quieres crear una rama a partir de una confirmación anterior. ¿Cómo harías eso? ? En Git, cada confirmación tiene un identificador único. Así que puedes ver esto fácilmente usando el comando «git log». Para crear una nueva rama basada en una confirmación específica, simplemente pasa su hash como parámetro al comando de la rama:

git branch new-branch 7e4decb

Aparte, ni siquiera necesitas todo el hash la mayor parte del tiempo. Solo los primeros cinco o seis caracteres lo harán.

Creación de una rama a partir de una etiqueta

Si tiene un poco más de experiencia con Git, entonces debería estar familiarizado con el concepto de etiquetas. Usas etiquetas para indicar que una determinada confirmación es importante o especial de alguna manera. Por ejemplo, las etiquetas generalmente se usan para indicar las versiones reales de un producto. Si has estado trabajando en tu aplicación por un tiempo y cree que es hora de lanzar la versión 1.0, lo que normalmente haría es aumentar los números de versión cuando sea necesario, confirmar esos cambios y luego agregar una etiqueta a ese momento específico. Para crear una etiqueta, normalmente ejecutaría algo como esto:

git tag -a v1.0 -m "First major version"

El parámetro «-a» indica que esto va para ser una etiqueta anotada. En contraste con una etiqueta liviana, este es un objeto Git completo, que contiene información como el nombre y correo electrónico del autor de la confirmación, la marca de tiempo y un mensaje. Ahora tiene una etiqueta, una indicación de que este punto particular de la historia es especial y tiene un nombre. Lindo. Puedes seguir trabajando, como de costumbre, creando y comprometiendo cambios que serán parte de la versión 1.1. Hasta que llegue un informe de error. Algunos clientes que se actualizaron al 1.0 del producto dice que una función de importación no funciona según lo previsto. Bueno, en teoría, podría corregir el error en la rama maestra e implementarlo. Pero luego los clientes recibirían funciones que posiblemente no se hayan probado y estén incompletas. -No. Entonces, ¿Qué haces? La respuesta: crea una nueva rama a partir de la etiqueta que ha creado para indicar la versión principal. Soluciona el problema allí, compila e implementa. Y probablemente debería volver a fusionar esto con el maestro después, para que las próximas versiones contengan la solución. . ¿Cómo lo haría? Fácil:

git branch <NAME-OF-THE-BRANCH> <TAG>

Más específicamente, usando nuestro ejemplo anterior:

git branch fix-bug-123 v1.0

Después de eso, puedes revisar tu nueva rama como de costumbre. O mejor aún, puedes hacerlo todo en un solo paso:

git checkout -b fix-bug-1234 v1.0

Creación de una rama en estado de cabecera independiente

¿Alguna vez ha deseado volver atrás en el tiempo? Con Git esto es posible … al menos en lo que respecta a los archivos en nuestro repositorio. Puede, en cualquier momento, verificar una confirmación si conoce su hash:

git checkout <SHA1>

Después de ejecutar eso, Git te mostrará un mensaje curioso:

You are in "detached HEAD" state. You can look around, make experimentalchanges and commit them, and you can discard any commits you make in thisstate without impacting any branches by performing another checkout.

Cuando revises una confirmación, ingresa a un estado especial c llamado, como puede ver, «CABEZA separada». Si bien puede realizar cambios en este estado, esas confirmaciones no pertenecen a ninguna rama y se volverán inaccesibles tan pronto como revise otra rama. Pero, ¿qué sucede si desea mantener esas confirmaciones? La respuesta, como era de esperar, es usar el comando «checkout» de nuevo para crear una nueva rama:

git checkout <sha1> #now you"re in detached head state# do some work and stage itgit commit -m "add some work while in detached head state"git branch new-branch-to-keep-commitsgit checkout new-branch-to-keep-commits

Y, por supuesto, ya sabes que puedes escribir el las últimas dos líneas como un solo comando:

git checkout -b new-branch-to-keep-commits

Bastante fácil, ¿verdad?

Simplemente porque puedes … No significa que debas

El modelo de ramificación de Git es uno de sus puntos de venta. Convierte lo que en otros sistemas de control de fuente es un proceso doloroso e incluso lento en una brisa. Se podría decir que Git ha democratizado con éxito la ramificación para las masas. Pero existe un grave peligro. Debido a lo económico de la ramificación en Git, algunos desarrolladores pueden caer en la trampa de trabajar con ramificaciones de larga duración o emplear flujos de trabajo o modelos de ramificación que retrasan la inte gración. Nosotros, como industria, hemos estado allí. Lo hemos hecho. No funciona. En su lugar, adopte flujos de trabajo que empleen ramas de vida extremadamente corta. Tendrá una caja de arena segura en la que codificar sin temor a romper cosas o hacer perder el tiempo a sus compañeros de trabajo. Pero, ¿eso le hace preguntarse, «¿Cómo implemento código con funciones parcialmente completadas?» En ese caso, se trata de indicadores de funciones al rescate. Las ramas de Git son una herramienta poderosa. Úselos sabiamente y no abuse de ellos. Y cuando no sean suficientes, emplee la entrega continua / integración continua junto con indicadores de funciones, incluidas herramientas especializadas a su disposición, para que sus aplicaciones puedan pasar al siguiente nivel.