¿Cómo se usa generalmente git? Un par de comandos básicos para " sincronizar a todos ". La frustración de Git a menudo surge entre aquellos que nunca van más allá de esta comprensión superficial. Sin embargo, dominar git seguramente valdrá la pena. ¿Cuánto tiempo pasas usando git? Sugeriría que en su cinturón hay muchas herramientas que usa la mitad de las veces y pasa el doble de tiempo estudiando.



Si desea obtener más información sobre git, sugiero comenzar con el capítulo 10 de Pro Git (¡es gratis!), Luego los capítulos 2, 3 y 7. El resto es opcional. En este artículo, discutiremos cómo usar las herramientas descritas en el libro para un trabajo disciplinado y productivo en git.

Lo básico: buenas descripciones de compromiso

Es posible que haya escuchado esto antes, pero sea paciente. En general, no necesita usar git commit -m " " . Comience configurando git para usar su editor favorito: git config --global core.editor vim , luego simplemente ejecute git commit . El editor se abrirá y usted puede escribir su descripción de la confirmación en él. La primera línea debe limitarse a 50 caracteres y completarse con una oración: después de aplicar este compromiso ... "arreglará la representación del texto en los idiomas CJK", "agregará soporte para el protocolo v3", "refactorizará el procesamiento CRTC", etc. Luego agregue una línea vacía y continúe con la descripción ampliada del compromiso , que debe estar codificado en 72 columnas e incluir detalles como la justificación del compromiso, compensaciones, restricciones de enfoque, etc.

Usamos 72 caracteres porque este es el ancho estándar de un mensaje de correo electrónico , y el correo electrónico es una herramienta importante para git. Se utiliza un límite de 50 caracteres porque la primera línea se convierte en el asunto de su correo electrónico, y puede agregar una gran cantidad de texto como “[PATCH linux-usb v2 0/13]” . Puede encontrar estas restricciones de formato molestas y onerosas, pero tenga en cuenta que otros leen los registros en un contexto diferente al suyo. A menudo leo registros de confirmación en un monitor vertical, y no comprime tanto texto en una línea como su pantalla 4K 16: 9.

Cada commit debe ser un cambio autónomo

Cada confirmación debe contener solo un cambio: evite pequeños cambios no relacionados en una confirmación (a este respecto, con mayor frecuencia podría escuchar mis propios consejos). Además, evite dividir un cambio en varias confirmaciones, a menos que la idea se divida en pasos separados, cada uno de los cuales representa un cambio completo. Si hay varios cambios en su árbol de trabajo y necesita confirmar solo algunos de ellos, intente git add -i o git add -p . Además, cada confirmación debe compilarse, pasar con éxito todas las pruebas y evitar errores conocidos que se corregirán en futuras confirmaciones.

Ahora puede realizar cualquier confirmación y esperar que el código funcione correctamente. Esto será útil más tarde, por ejemplo, durante la inclusión selectiva de confirmaciones en la rama de lanzamiento. Este enfoque también mejora la utilidad de git-bisect ¹ , porque si espera que el código compile y pase las pruebas para cada confirmación con éxito, entonces puede pasar un script git-bisect que verifica programáticamente el árbol en busca de errores y evitará falsos positivos. Estas confirmaciones independientes bien descritas simplificarán la preparación de descripciones de lanzamiento utilizando git-shortlog , como lo hace Linux con los lanzamientos de Linux .

Es difícil hacerlo bien la primera vez

Llegamos a una de las características más importantes de git, que la distingue de sus predecesoras: la edición de historias. Todos los sistemas de control de versiones vienen con algún tipo de "máquina del tiempo", pero antes eran principalmente de solo lectura. Sin embargo, la máquina del tiempo git es diferente: puedes cambiar el pasado. De hecho, ¡incluso te animamos a hacer esto! Pero te advierto: solo cambia el pasado, que aún no ha entrado en una rama pública estable.

La conclusión es la siguiente. Escribir confirmaciones sin errores, las confirmaciones autónomas con una buena descripción es difícil en el primer intento. Editar una historia, por otro lado, es fácil, y es parte de un flujo de trabajo eficiente de git. Echa un vistazo a git-rebase y úsalo libremente. Puede usar rebase para reordenar, fusionar, eliminar, editar y dividir commits. Por ejemplo, generalmente hago algunos cambios en el archivo, envío una confirmación de reparación ( git commit -m fixup ) y luego uso git rebase -i para fusionarlo en una confirmación anterior.

Varios consejos

• Leer maná! Seleccione una página de manual de git aleatoria y léala ahora. Además, si no ha leído la página de manual de git de nivel superior (solo man git ), haga esto.
  
• En la parte inferior de cada maná para un comando git de alto nivel suele haber una lista de comandos git de bajo nivel en los que se basa el comando de alto nivel. Si desea obtener más información sobre cómo funciona el comando git de alto nivel, intente leer estas páginas de manual.
  
• Aprenda a seleccionar los commits correctos con la selección de revoluciones .
  
• Las ramas son útiles, pero debes aprender a trabajar sin ellas, y también tener un buen conjunto de herramientas en tu cinturón. Utilice comandos como git pull --rebase , git send-email -1 HEAD~2 y git push origin HEAD~2:master .

1. En pocas palabras, git bisect es una herramienta que realiza una búsqueda binaria entre dos confirmaciones en su historial, observando las confirmaciones entre ellas una a la vez para que pueda verificar un error. De esta manera, puede calcular la confirmación que causó el problema. ↑