Uso y flujos de trabajo avanzados de Git

Recientemente analizamos los conceptos básicos para comenzar a usar Git para el control de código fuente en sus proyectos. Si bien ese es un excelente punto de partida, hay muchos otros comandos y flujos de trabajo de Git que lo ayudarán a familiarizarse con el uso de Git en su trabajo diario de codificación.

Flujos de trabajo Git

Cuando comencé a usar Git, pensé que sabía cómo usarlo correctamente. Mi enfoque ideal era hacer todos los cambios en un solo lugar sin bifurcaciones y luego enviarlos al repositorio y seguir trabajando.

Si bien era mejor que no usar el control de versiones, me tomó un tiempo darme cuenta de que no estaba usando la mayor parte del poder que proporcionaba Git. Para que Git funcionara para mí, necesitaba tener una estrategia para bifurcar y fusionar mis cambios.

Luego salió git-flow y lo adopté como mi estrategia. Todavía recuerdo sentir que estaba mirando detrás de una cortina donde estaban los increíbles desarrolladores. Ahora tenía una idea de cómo funcionaban y podía comenzar a convertirme en uno de ellos.

Pero git-flow no se adapta a todos los escenarios, así que mientras lo analizamos, también veremos algunos otros métodos para mantener sus proyectos de Git organizados, incluida la forma en que administro mis proyectos como desarrollador solitario.

git-flujo

Mirando git-flow ahora, reconozco que el panorama del software ha cambiado mucho en 10 años y que git-flow puede no ser la mejor opción para su equipo. Cuando se escribió git-flow, era raro implementar una aplicación muchas veces al día. En cambio, probablemente hizo un número de versión principal y lo lanzó cada pocos meses o semanas si estaba en un equipo particularmente ágil.

Echemos un vistazo a lo que es git-flow.

Si desea ver la explicación completa y profunda con gráficos y comandos de Git para Git Flow, debe leer esta publicación.

En git-flow, dos ramas tienen un tiempo de vida infinito. Primero, main, que debe reflejar el código que está listo para implementarse en su entorno de producción/en vivo.

En segundo lugar, tenemos nuestra rama de desarrollo. Esta rama debería tener los últimos cambios que están listos para la próxima versión de nuestro software. Cuando los cambios en desarrollo están listos para implementarse en nuestra aplicación en vivo, los fusionamos en la rama principal y los etiquetamos con el número de versión que corresponde con el número de lanzamiento.

Fuera de las dos ramas principales, hay tres tipos de ramas de apoyo.

1. Característica

Una bifurcación de características solo se puede crear desde la rama de desarrollo. Debe volver a fusionarse con la rama de desarrollo. El nombre puede ser cualquier cosa que describa la función en la que está trabajando.

Cuando el trabajo está listo para el próximo lanzamiento, se vuelve a fusionar con la rama de desarrollo donde espera el momento del lanzamiento.

2. Liberación

Las ramas de lanzamiento se crean a partir de la rama de desarrollo y deben volver a fusionarse tanto con el desarrollo como con el principal. Usted nombra una rama de lanzamiento con la convención release-x. En la práctica, eso generalmente significa que nombraría una rama con el número de versión que planea usar así: versión-2.2

Utiliza una rama de lanzamiento como una forma de hacer la preparación final para lanzar su software. Esto puede incluir aumentar el número de versión de los archivos, asegurarse de que sus traducciones estén hechas o verificaciones finales del código.

3. Revisión

La rama de revisión se crea a partir de la rama principal y se usa para contener cambios que deben tratarse en la aplicación en vivo de inmediato. Esto puede ser un error que debe corregirse o un problema de seguridad que debe solucionarse.

Una vez que el problema se solucione y se implemente en su sucursal principal, etiquetará su código con el número de versión adecuado.

La principal razón por la que los equipos no usan git-flow ahora es que la forma en que lanzamos el software ha cambiado. En lugar de lanzamientos más grandes con menos frecuencia, puede lanzar un cambio en una aplicación varias veces al día. Sé que envío trabajo a los sitios de mis clientes muchas veces a la semana tan pronto como está listo. No hacemos números de versión del sitio, simplemente seguimos mejorándolo.

El flujo de git estándar no está diseñado para adaptarse a esto.

Flujo de Github

La segunda opción que mucha gente usa es Github Flow.

La gran regla de Github Flow es que cualquier código que esté en la rama principal se puede implementar en cualquier momento porque está listo para producción.

Todas las ramas se crean a partir de la rama principal con un nombre descriptivo para lo que sea que estés haciendo.

Una vez que tenga sus cambios listos, cree una solicitud de extracción.

Las solicitudes de extracción le dicen a otros que trabajan en el mismo código que el trabajo que está haciendo está listo para ser revisado antes de que esos cambios se fusionen en el código principal.

Una vez que haya enviado una solicitud de extracción, el equipo con el que está trabajando puede revisar los cambios y proporcionar comentarios. Si se considera que la solicitud de extracción está lista para fusionarse, entonces se fusiona con la rama principal de su proyecto.

Un inconveniente del flujo de Github para un solo desarrollador o un equipo muy pequeño es que la administración de una solicitud de extracción puede crear una sobrecarga adicional en la gestión del proyecto. Es por eso que no los uso en mi trabajo.

Cómo uso los flujos de trabajo de Git con proyectos de clientes

En el trabajo de mi cliente, generalmente soy el único que escribe código diariamente para un proyecto. Mi cliente puede actualizar los complementos de WordPress o cambiar algunos CSS, pero no realizan ningún trabajo de codificación importante. Eso significa que si sigo con el flujo de Github, estaría revisando mis solicitudes de extracción, lo que solo crea dolores de cabeza de administración adicionales. Veamos el sistema que uso, que se parece tanto a git-flow como a Github flow.

Tengo dos ramas principales llamadas main y staging. La rama principal rastrea con cualquier código que se esté ejecutando actualmente en el sitio de producción. La rama de ensayo realiza un seguimiento de lo que se está probando en el sitio de ensayo que usamos para probar los cambios antes de enviarlos al sitio en vivo.

Cada rama se crea a partir de la rama principal. Las nuevas características reciben un nombre como este: característica/32-nueva-característica. En este contexto, el número 32 corresponde al número de ticket en nuestro sistema de gestión de proyectos y las palabras posteriores son una breve descripción de lo que se está trabajando. Las correcciones de errores se denominan de manera similar, bug/20-bug-name.

Cada rama creada se fusiona primero con nuestra rama provisional y luego, una vez aprobada por el cliente o probada por mí mismo, se fusiona con la rama maestra. Ese flujo de trabajo puede verse así.

# fusionar la función en la rama de preparación

git merge función/32-nueva-función

# implementar y probar la característica

git pago principal

git merge función/32-nueva-función

# implementar la función en el sitio en vivo

En mis proyectos, tengo una configuración de implementación continua, lo que significa que cada vez que envío código a main, se envía automáticamente al sitio en vivo. El mismo proceso se configura para la rama de ensayo.

Si estuviera trabajando con un equipo que pudiera verificar mi código en un flujo de trabajo de solicitud de extracción, entonces usaría este sistema porque funciona bien en un equipo. Para un desarrollador que trabaja principalmente por su cuenta, es simplemente la sobrecarga de administración lo que ralentizará su flujo de trabajo.

Comandos avanzados de Git que uso

Ahora que tenemos una idea de cómo podemos usar Git en un flujo de trabajo práctico, echemos un vistazo a los comandos más avanzados que se necesitarán para que esto suceda. Uso cada uno de estos comandos al menos algunas veces a la semana mientras trabajo con el código de mi cliente.

Incluso si va a utilizar una aplicación GUI (mencioné algunas buenas en mi última publicación sobre Git), es importante comprender lo que sucede en segundo plano. Muchas veces he tenido que trabajar a través de la terminal para solucionar un problema creado por una aplicación GUI de Git.

Adición de cambios por línea

El único comando que hizo que el uso de Git a través de Terminal click para mí fuera git add -p. Hasta que aprendí este comando, usaba aplicaciones GUI porque hacía cambios en mi código pero quería dividir líneas específicas en diferentes confirmaciones para poder explicar por qué había hecho un cambio. Para hacer esto, utilicé una GUI para seleccionar las líneas, pero git add -p lo guía a través de una interfaz interactiva para agregar cambios en fragmentos.

Lo uso muchas veces al día.

Seguimiento de la sucursal remota de Git

Si está descargando un repositorio existente y tiene ramas como principal y puesta en escena de las que necesita realizar un seguimiento pero que ya existen, debe indicarle a sus versiones locales de las ramas que rastreen esas versiones remotas de la rama.

Hay algunas maneras de hacer esto.

# Configurar aguas arriba al presionar a control remoto

git push -u puesta en escena de origen

# Establecer aguas arriba

# asume que está en la sucursal que desea rastrear actualmente con el control remoto

git rama -u origen/puesta en escena

rama git --set-upstream-to=origen/puesta en escena

# Si no está en la rama que desea rastrear, especifique la rama al final

git branch --set-upstream-to=origin/staging staging

Guardar cambios sin confirmarlos

A veces, estará en medio de algún trabajo que aún no está listo para confirmarse, pero necesita guardar su estado. Ahí es donde git stash es útil. Este comando oculta los cambios para usted al eliminarlos. Puede recuperarlos usando git stash pop. Hay algunos comandos más para hacer que Stash sea útil, pero esos son los dos que uso regularmente.

Extraiga una confirmación de Git específica

A veces es necesario incluir una confirmación específica en su trabajo actual. Con un HEAD limpio (aún no ha realizado ningún cambio), puede obtener una confirmación específica con git cherry-pick. Puede encontrar la documentación completa en git cherry-pick aquí.

Para cada confirmación, Git crea una secuencia larga de letras y números que se denomina Objeto Git y comúnmente se conoce como SHA. Dado que cada compromiso obtiene uno, puede hacer referencia a un compromiso con su valor SHA. Obtenga más información sobre los objetos de Git.

Deseche los cambios que no necesita

En algún momento de cualquier proyecto, haremos cambios y luego nos daremos cuenta de que no está funcionando y simplemente debemos desecharlos y comenzar de nuevo. En lugar de simplemente intentar deshacer hasta que volvamos a donde queremos estar, podemos usar el siguiente comando de Git para eliminar cualquier cambio que aún no se haya rastreado.

git reset --difícil

El comando anterior restablecerá su código a la confirmación más reciente en la rama en la que está trabajando actualmente. También podríamos usar un <#commitSHA> con este comando para restablecer una confirmación específica si quisiéramos volver a un estado anterior a la última confirmación. Tal vez usaría esto para restablecer el pago de la rama inicial porque el trabajo de la rama completa no es algo que desee conservar, pero ya había rastreado parte del trabajo.

Para ir un paso más allá, podemos desechar cualquier archivo o directorio que aún no haya sido rastreado en git con el comando git clean.

git clean -fd: las banderas f y d le dicen a git que deseche los archivos y directorios que no están rastreados.

Eliminar sucursales

Cada semana o dos miro los resultados de un comando de estado de git y descubro que tengo demasiadas ramas para entender razonablemente lo que está pasando en mi repositorio. Eso significa que puedo eliminar cualquier rama que corresponda a tickets que se hayan resuelto con los siguientes comandos.

# elimina la versión local

git rama -d $ nombre de la rama

#elimina la rama en mi control remoto

git push $remotename --delete $branchname

Usar control de versiones

Si bien es posible que no sea un experto en todos los comandos de Git que usará, una cosa importante que debe recordar es que debe usar el control de versiones . Incluso si es la única persona que trabaja en un proyecto, usar Git y un flujo de trabajo de Git lo ayudará a mantener sus proyectos organizados. No necesitará presionar CTRL + Z hasta que haya reiniciado su trabajo después de escribir código que no funcionó.

Podrá confiar en su sistema y seguir produciendo trabajo para sus proyectos.

Pruebe el alojamiento de WordPress totalmente administrado

¿Necesita un alojamiento optimizado para WordPress? Consulte los planes de alojamiento de WordPress totalmente administrados de Nexcess hoy.