¿Debería cada git commit dejar el proyecto en un estado de trabajo?

Tengo curiosidad por saber cuál es la mejor práctica predominante. ¿Deben ejecutarse las confirmaciones de git de modo que el proyecto se encuentre en un estado de funcionamiento (se compila correctamente, todas las pruebas pasan, etc.) o está confirmando que el código no funciona?

Por ejemplo, si renuncia a este requisito, puede ser más flexible con las confirmaciones (úselas como fragmentos lógicos, aunque la aplicación no esté funcionando, etc.). Sin embargo, si lo aplicas, obtienes la flexibilidad de poder elegir cualquier compromiso dado más adelante ...

Usualmente sigo esta regla:

• Cada fusión para masterramificarse debe dejar el proyecto en un estado de trabajo;
• Cada fusión a la developrama de la línea principal debe dejar el proyecto en un estado de trabajo (y debe construir al menos);
• Cada uno de los compromisos individuales tiene el objetivo principal de explicar por qué se realiza el cambio, para qué sirve y qué partes del proyecto afectó. Todos los demás objetivos, como dejar el proyecto en un estado de trabajo, son opcionales.

Use su clon local del repositorio para lo que sea que lo haga sentir cómodo durante el desarrollo.

Cometo código roto regularmente, y cuando estoy listo para poner el código a disposición de otros desarrolladores, utilizo una excelente función:

git rebase -i HEAD~4

Esto me permite comprimir mi intermediario (en este caso, 4 de ellos), posiblemente roto, se compromete en una buena confirmación. Se le presentará un editor que le permitirá elegir cómo se compactarán esas confirmaciones. Por lo general, marqué el primer commit el 'pick' commit, y marque el resto 'squash'.

Entonces puedo impulsar esa confirmación atómica, o de hecho lo que hago si mi nueva característica está realmente lista, es usar 'git cvsexportcommit' para llevar mi trabajo al repositorio CVS existente.

Dos de los grandes beneficios del control de versiones es que les permite a los desarrolladores recuperar versiones anteriores de su trabajo, y les permite probar cambios diferentes y posiblemente conflictivos al mismo tiempo. El control de versiones brinda a los desarrolladores la libertad de probar ideas que podrían fallar.

Se debe alentar a los desarrolladores a ramificarse y comprometer su trabajo regularmente, ya sea que se desarrolle o no. Negarse a permitir la bifurcación o las confirmaciones rotas es estorbar a sus desarrolladores y hacer un mal uso de sus herramientas.

Dicho esto, es una práctica excelente exigir que los compromisos con ciertas ramas siempre se desarrollen. Muchas organizaciones van más allá y prohíben a los desarrolladores comprometerse con ciertas sucursales. Por ejemplo, se podría requerir que los desarrolladores fusionen su trabajo con la rama de desarrollo principal, pero solo el desarrollador principal podría fusionar esos cambios del desarrollo a la rama de producción.

Generalmente seguimos ambos enfoques. En el repositorio local de mi caja, confirmo todo lo que quiero. Cuando llega el momento de pasar al repositorio central de mi equipo, primero hago un rebase interactivo y moldeo mis confirmaciones en paquetes lógicos. Por lo general, una confirmación por historia, con la identificación de la historia (o defecto) incluida en el comentario (somos una tienda basada en kanban).

Luego, en nuestra reproducción central, tenemos a Jenkins escuchando y comienza la compilación y todas las pruebas. Si algo falla, generalmente permitimos que las personas intenten arreglar la compilación con otra confirmación. Si no se ve bien, revertir la confirmación defectuosa es fácil de hacer.

Como git commitsolo afecta a su propia copia del repositorio, no es necesario que el proyecto esté en funcionamiento después de cada confirmación. Siga adelante y comprométase cuando quiera guardar el trabajo que ha hecho. Probablemente, una buena regla general es que una confirmación es apropiada cuando puede describir los cambios que ha realizado en el mensaje de confirmación.

Es lo git pushque afecta a otros usuarios. Las políticas sobre lo que se debe impulsar son una cuestión que debe decidir su equipo de desarrollo. Presionar el código que no funciona en la rama principal es probablemente un no-no, pero probablemente esté bien insertar el código que no funciona en una rama separada (siempre y cuando nadie más intente hacer una compilación desde esa rama).

Estamos usando git flow en el trabajo, y también cometemos código inacabado o roto, ya que solo aterriza en sucursales locales o remotas hechas para ese problema específico. Solo una vez que finaliza la tarea, se fusiona en la rama de desarrollo (que representa la copia de trabajo actual en el modelo de flujo). De esa manera, también podemos colaborar en el código (algunos compañeros de trabajo están en otra ciudad, incluido el líder del proyecto) y ayudarse mutuamente.

Sin embargo, depende de cómo estén pensando usted y sus compañeros de trabajo. Personalmente, creo que las confirmaciones de sucursal están bien, ya que es posible que necesite un historial de cambios con un refactor más grande o similar.

En última instancia, depende de usted y de las personas con las que trabaja o para las que trabaja, ya que git no impone ninguna regla.

Mi práctica es evitar cualquier compromiso que intencionalmente empeore significativamente el sistema. Cada confirmación debe refactorizar o implementar algún requisito. Si hago una mala confirmación y la descubro antes de presionarla, la enmendaré o volveré a modificar para eliminarla del historial.

Creo que esto hace que sea más fácil leer el registro de git en una solicitud de extracción, ya que cada confirmación debe ser independiente como una refactorización o una implementación de algún requisito. Agregar un código muerto que cobrará vida en el futuro cercano cuenta como una refactorización. Estos son mis "fragmentos lógicos".

Aún puede ser flexible con la forma en que estructura sus commits. Por ejemplo, puede escribir pruebas por adelantado, pero marcarlas como omitidas en la primera confirmación, para que su conjunto de pruebas no informe un error y luego omitirlas cuando finalice la implementación.

Suponiendo que está utilizando sucursales y buenos mensajes de confirmación, cometer código "roto" en una rama con un mensaje de confirmación que lo aclare estaría bien, siempre que su equipo acuerde que es una buena práctica de trabajo.

También clona el repositorio de git localmente, por lo que bien podría tener una rama local con confirmaciones locales no enviadas al origen donde está cometiendo código "roto" a medida que avanza; luego, cuando lo tenga todo funcionando, puede fusionarlo en master o alguna otra rama, y ​​eliminar su rama de trabajo con los varios commits "rotos".

Para mí, se trata de acordar con su equipo lo que es aceptable; algunos equipos no aceptarán código roto incluso en una sucursal, otros lo harán.