Git commit style: ¿Todos los archivos cambiados a la vez o de uno en uno?

Question

Estoy guardando mi trabajo por la noche con una única confirmación para muchos archivos. Me pregunto si sería mejor comprometerse con cada archivo, pero esto parece mucho más trabajo.

No tengo ningún problema con la forma en que están las cosas ahora, pero planeo poner mi código en GitHub y quiero que sea fácil de entender.

Me pregunto qué está haciendo el resto de ustedes que usan git. También si pudieras deletrearlo por mí. Soy nuevo en Git y he estado usando TortoiseGit y gitk en Windows.

Answer 1

Cuándo cometer y qué cometer es un arte, y no hay reglas en blanco y negro. Dicho esto, hay hábitos que son más fáciles de entender que otros.

En general, creo que debe optimizar sus compromisos para la comprensibilidad. Si vuelve y lee el diff para la confirmación, ¿puede averiguar qué logró en los cambios?

Si desea ser más específico, he aquí una larga lista de lo que creo que son y no hacer hacer:

• No se comprometa después de cada pequeño cambio sencillo - cada línea cambia, todos los ficheros cambiados , etc.
• No trabaje durante todo un día y realice un compromiso gigantesco al final del día.
• Realice separaciones para diferentes funciones, p. Ej. desarrollando la característica foo vs. solucionando la falla # 2.
• Haga una confirmación por separado para mover/cambiar el nombre de los archivos, porque es más fácil para Git seguir de esta manera.
• ¿Piensas en optimizar para la revertecidad: si no te gusta un cambio que hiciste, ¿es fácil deshacerlo incluso después de que se hayan acumulado nuevos cambios en la parte superior?

Answer 2

"fácil de entender" significa también:

• comete representando no sólo "punto de control" (como lo harían si comprometida después de cada modificación del archivo), pero un estado coherente del código
• fácil de git bisect (es decir, cada confirmación debería representar un cambio en una tarea , que compila y añadir una evolución o una nueva característica, y no un "puesto de control comprometerse", lo que haría que la git bisect falla demasiado pronto)

Ver "understanding the Git workflow" para más: es necesario diferenciar:

ramas

• privados (que nunca empujar), donde se puede cometer, básicamente, en cualquier momento, y
• poderes públicos (que se quiere presione en GitHub), que necesita limpieza y compromisos significativos.

Así que preste atención al "fast-forward" merge that Git uses by default: no olvide limpiar el historial de las sucursales que está a punto de fusionarse de esa manera en las sucursales públicas.