Consejos de Git de los profesionales

Ya estás usando el control de fuente para administrar tu código, ¿verdad? Incluso podrías estar usando tu SCM como la pieza central de tu flujo de trabajo, como lo hacemos en New Relic.

En este artículo, no vamos a revisar los conceptos básicos de la gestión del control de fuente, independientemente de cuál utilices. Supongamos que ya sabes cómo moverte. Lo que vamos a cubrir es cómo los profesionales usan git. Echaremos un vistazo a algunas de las funciones avanzadas y los flujos de trabajo con los que es posible que aún no estés familiarizado. ¡Con suerte, te irás con la boca abierta ante las grandes posibilidades que ofrece git!

Si eres como yo, te encantará explorar cómo trabajan otros desarrolladores.

Para los no iniciados, o aquellos que vienen de otro SCM, Git es un sistema de control de versiones distribuido. Es gratuito y de código abierto, ocupa poco espacio y puede adaptarse al flujo de trabajo que más te convenga. Por lo general, no te obliga a trabajar de una manera particular, lo que significa que existen muchas metodologías diferentes sobre cómo usar sus funciones, como áreas de ensayo, ramificaciones y etiquetado de lanzamientos. Si eres como yo, te encantará explorar cómo trabajan otros desarrolladores. Así que prepárate para empezar a modificar tu .gitconfig, porque te espera un capricho. Veamos cómo los profesionales usan git.

Organiza tus cambios en Hunks

Es probable que estés familiarizado con la modificación accidental de un solo archivo por dos razones diferentes sin enviar un commit.

Ciertamente, estás familiarizado con la adición de archivos al área de preparación con el comando add con el nombre apropiado. Y probablemente estés familiarizado con la modificación accidental de un solo archivo por dos razones diferentes sin enviar un commit. Por lo tanto, seguramente tendrás un registro de git log de mensajes como "Editar X y cambiar Y no relacionado". Si esto suena como tu flujo de trabajo, entonces la adición interactiva es tu nuevo mejor amigo.

La adición interactiva, o la adición de un parche, te guía a través de los cambios, un trozo a la vez. Cuando agregas un archivo con el comando -p, se te solicitará cada cambio lógico (es decir, las líneas editadas sucesivamente se agruparán). Hay una serie de elecciones que puedes hacer en cada trozo, desde dividir el trozo actual en otros más pequeños, omitir un trozo o incluso editarlo manualmente. Utiliza la opción ? para ver una lista completa de comandos.

Comenzar con la puesta en escena de trozos es tan simple como:

git add -p <FILE>

Echa un vistazo a tu última rama

Como buen ciudadano de la codificación, cuando te encuentras con algo que necesita una solución rápida o una limpieza, probablemente deberías tomarte un momento para cambiarlo. Pero si estás utilizando un flujo de trabajo de rama de características pesada, entonces no querrás esa solución no relacionada en tu rama de características. Esto significa que deberás guardar tus cambios actuales mediante stash, cambiar a tu rama maestra y luego hacer la corrección allí. Rebotar entre ramas puede ser tedioso, pero, afortunadamente, hay un atajo rápido para cambiar a la última rama. (por Zach Holman)

git checkout -

Esta sintaxis debería resultar bastante familiar para los usuarios de *NIX. El comando cd tiene un atajo similar (cd -) que saltará al último directorio en el que estabas. Nunca tendrás que recordar cómo llamaste a esa rama de función cuando necesites volver a cambiar; solo usa git checkout -.

Mostrar qué ramas están fusionadas (o no)

Al trabajar con ramas de características, puedes crear rápidamente tantas que desordenan la salida de git branch --list. De vez en cuando deseas deshacerte de las ramas que has convertido en maestra. Pero probablemente tengas una pausa rápida antes de git branch -d <BRANCH>, pero con los siguientes comandos puedes eliminarlos con confianza sin pensarlo dos veces. (por Zach Holman)

Si deseas ver qué ramas locales tienes que están fusionadas con la rama en la que te encuentras actualmente, todo lo que necesitas es:

git branch --merged

El reverso también está disponible. Se pueden ver qué ramas no se han fusionado en la rama seleccionada actualmente mediante:

git branch --no-merged

Combina esto con un par de herramientas sencillas de UNIX y podrás eliminar rápidamente todo lo que ya se ha fusionado:

git branch --merged | xargs git branch -d

Tomar un archivo de otra rama sin cambiar de rama

Digamos que estás experimentando con algunas refactorizaciones y tienes algunas ramas que tienen varios cambios que has realizado. Si tienes cambios en un archivo en alguna rama distante que deseas traer a tu rama de trabajo actual, entonces puedes realizar cualquier número de pasos. Sin la sugerencia a continuación, probablemente guardarías tus cambios actuales, cambiarías de rama y tomarías el contenido del archivo que deseas cambiar, volverías (con git checkout -, por supuesto) y realizarías tus ediciones. O simplemente puedes verificar solo ese archivo que lo fusionarás en tu rama actual (por Zach Holman):

git checkout <BRANCH> -- path/to/file.rb

Ramas de Git ordenadas por el último Commit

Así que ya tienes la lista de ramas desordenada de la que hablamos antes; algunas de las que has limpiado con la bandera --merged. Pero, ¿qué pasa con todas esas otras ramas? ¿Cómo saber cuáles son útiles o están completamente desactualizadas? El comando for-each-ref generará una lista para cada rama y mostrará la información de referencia para el último commit. Podemos personalizar la salida para incluir información útil, pero, lo que es más importante, podemos ordenar la lista por fecha. Este comando nos dará una lista de ramas con el último mensaje del commit y quién lo ha enviado, ordenadas en orden de fecha descendente. (por Rein Henrichs)

git for-each-ref --sort=-committerdate --format='%(committerdate:short) %(refname:short) [%(committername)]'

Si bien puedes escribir este comando cada vez, te recomiendo encarecidamente convertirlo en un alias y evitarte algunos dolores de cabeza.

git config --global alias.latest "for-each-ref --sort=-committerdate --format='%(committerdate:short) %(refname:short) [%(committername)]'"

Las personas en las casas de cristal no deberían usar Git Blame

O al menos no deberían usar git blame sin uno de los indicadores de opciones a continuación. Git blame es poderoso; es básicamente como usar la ciencia para demostrar que tienes razón. Pero ten cuidado, muchos cambios son superficiales y encontrar la fuente real del código en cuestión requiere un poco más de búsqueda. Cosas como eliminar espacios en blanco, mover texto a nuevas líneas o incluso mover texto de otro archivo se pueden ignorar para llegar al autor original del código mucho más fácilmente.

Antes de usar git blame, asegúrate de marcar uno de estos:

git blame -w  # ignores white space
git blame -M  # ignores moving text
git blame -C  # ignores moving text into other files

Encontrar una cadena en todo el historial de Git (y eliminarla)

De vez en cuando, debes buscar una línea de código que sabes que escribiste pero que simplemente no puedes encontrar. Podrías estar atascado en alguna rama distante, borrado hace mucho, mucho tiempo, o escondido en un lugar llano; pero de cualquier manera, puedes encontrar cualquier cadena en todo tu historial de git combinando algunos comandos. Primero, obtendremos una lista de todos los commits y luego mediante grep buscaremos en cada uno de ellos para nuestra cadena.

git rev-list --all | xargs git grep -F '<YOUR STRING>'

Probablemente tengas un amigo que haya enviado accidentalmente datos confidenciales a un repositorio: claves de acceso, contraseñas, la receta secreta de marinara de tu abuela. Lo primero que deben hacer es cambiar sus contraseñas y revocar el acceso con esas claves (y disculparse con tu abuela). A continuación, querrás buscar el archivo ofensivo y eliminarlo de todo el historial de git, lo que suena mucho más fácil de lo que realmente es. Una vez que se completa este proceso, a cualquier persona que realice los cambios limpiados también se le eliminarán los datos confidenciales. Las bifurcaciones de tu repositorio que no combinan tus cambios anteriores aún contendrán los archivos modificados (por lo tanto, no omite el cambio de contraseñas y la revocación de claves de acceso).

Primero, reescribiremos el historial de git para cada rama, eliminando el archivo con los datos confidenciales.

git filter-branch --index-filter 'git rm --cached --ignore-unmatch <FILENAME>' --prune-empty --tag-name-filter cat -- --all

Agrega el archivo a .gitignore y envía un commit actualizando el .gitignore.

echo <FILENAME> >> .gitignore
git add .gitignore
git commit -m "Add sensitive <FILENAME> file to gitignore"

Dado que estamos reescribiendo el historial, deberás forzar la inserción de los cambios en tu control remoto.

git push origin master --force

Los archivos enviados todavía existen en tu repositorio local, por lo que deberás realizar algunas tareas de limpieza para purgarlos por completo.

rm -rf .git/refs/original/
git reflog expire --expire=now --all
git gc --prune=now
git gc --aggressive --prune=now

El repositorio de tu amigo debe estar libre de datos confidenciales y tú serás el héroe por ayudarlos con tu conocimiento pro en git. (por StackOverflow y GitHub)

Ignorar cambios en un archivo registrado

Trabajar con el código de otra persona en tu entorno puede significar que necesitas realizar cualquier cantidad de cambios de configuración para que la aplicación se ejecute. Es demasiado fácil enviar accidentalmente un cambio en esas configuraciones que estaban destinadas exclusivamente a tu entorno. Entonces, en lugar de estar siempre atento a esos archivos y hacer que permanezcan en el área de preparación "modificada", simplemente puedes decirle al índice git que ignore los cambios en ese archivo. Puedes pensar en esto como un archivo git ignorado que permanece con el repositorio. (por Arnaud Coomans)

git update-index --assume-unchanged <FILENAME>

Poner en cero la historia de una rama

A veces, empezar de cero es exactamente lo que necesitas hacer, por diversas razones. Tal vez hayas heredado una base de código que no puedes garantizar que sea segura para el código abierto, tal vez simplemente intentes algo completamente nuevo, o tal vez estés agregando una rama que tenga un propósito separado que desees mantener con el repo (como las páginas de GitHub). Para este caso, hay una forma muy sencilla de crear una nueva rama en tu repositorio que esencialmente no tiene historial. (por Nicola Paolucci)

git checkout --orphan <NEWBRANCH>

Alias sin los que no puedes vivir

Deja de perder el tiempo escribiendo comandos largos y crea algunos alias útiles.

Ninguna discusión sobre git estaría completa sin hablar de varios alias que literalmente te ahorrarán minutos al año en las pulsaciones de teclas guardadas. Deja de perder el tiempo escribiendo comandos largos y crea algunos alias útiles. Los alias se pueden crear agregándolos a tu archivo .gitconfig o usando la línea de comandos git config --global alias.<NAME> "<COMMAND>". A continuación, verás solo una muestra de alias que puedes usar como trampolín para ideas.

co: con un flujo de trabajo de rama de funciones, te moverás entre ramas con regularidad. Ahórrate seis caracteres cada vez.

co = checkout

ds: siempre es una buena práctica revisar los cambios que vas a realizar antes de enviarlos a tu repositorio. Esto te permite detectar errores tipográficos, la inclusión accidental de datos confidenciales y la agrupación de código en grupos lógicos. Organiza tus cambios y luego usa git ds para ver la diferencia de esos cambios.

ds = diff --staged

st: deberías estar bastante familiarizado con la salida detallada de git status. En algún momento querrás saltarte todas las formalidades y ponerte manos a la obra. Este alias muestra la forma abreviada de estado e incluye los detalles de la rama.

st = status -sb

amend: ¿olvidaste incluir un archivo en tu último commit, o tal vez tenías un ajuste que necesitabas hacer? Modifica los cambios por etapas de tu último commit.

amend = commit --amend -C HEAD

undo: a veces, modificar tu último commit no es suficiente y tendrás que deshacerlo en su lugar. Este alias retrocederá un commit y dejará los cambios de ese commit por etapas. Ahora puedes realizar cambios adicionales o volver a enviar un nuevo commit con un nuevo mensaje.

undo = reset --soft HEAD^

ls: trabajar en una base de código con un grupo de desarrolladores significa tratar de mantenerte al día con lo que la gente está trabajando. Este alias proporcionará un registro de git de una línea que incluye la fecha y el nombre de quien envió los cambios.

ls = log --pretty=format:"%C(yellow)%h %C(blue)%ad%C(red)%d %C(reset)%s%C(green) [%cn]" --decorate --date=short

standup: este alias es ideal para revisar lo que trabajaste ayer para cualquier tipo de standup diario, o simplemente para refrescar tu memoria por la mañana.

standup = log --since '1 day ago' --oneline --author <YOUREMAIL>

graph: un historial de git complejo puede ser difícil de revisar en línea recta. El uso de la bandera "graph" muestra cómo y cuándo se agregaron los cambios a la rama actual.

graph = log --graph --pretty=format':%C(yellow)%h%Cblue%d%Creset %s %C(white) %an, %ar%Creset'

Para concluir

Git puede ser increíblemente simple y alucinantemente complejo. Puedes comenzar con lo básico y trabajar tú mismo en una manipulación de gráficos más compleja a lo largo del tiempo. No es necesario asimilarlo todo antes de poder usarlo. El comando que será más poderoso a medida que aprendas es man git-<command>-<name>. Intenta usarlo antes de consultar a Google para obtener una respuesta.

Puedes obtener más información sobre cómo la empresa en la que trabajo para ti, New Relic, utiliza git en nuestro blog, o prueba New Relic Pro de forma gratuita. ¡Gracias por leer! Si tienes alguna pregunta, ¡cuéntanos a continuación!