Compromisos masivos vs Compromisos rápidos [cerrado]

Sé que la mayoría de ustedes recomendaría ir con la estrategia y la metodología del proyecto.

Sin embargo, solo tengo una pregunta rápida, desde el punto de vista de Senior, ¿qué sería mejor para ver pequeñas confirmaciones rápidas de un desarrollador, o una gran porción de código enviada a la rama?

Realmente no importa el tamaño, sino que commit debe ser lo más atómico posible. Con eso quiero decir que commit no debe romper la compilación, debe corregir un error específico o agregar una característica específica y ser independiente de cualquier otro commit. Si una función requiere mucho código, que así sea. Pero, por lo general, esta estrategia produce naturalmente pequeños compromisos frecuentes.

Hay límites, pero prefiero pequeños compromisos atómicos.

Primero, facilita las cosas cuando te refieres a por qué se hizo un cambio. En segundo lugar, reduce drásticamente el costo de cometer un error.

Sin embargo, hay dos notas de precaución:

Si está utilizando un VCS centralizado, solo confirme cuando se ejecuten las compilaciones de código y las pruebas. (Si está utilizando DVCS, reemplace "commit" con "push").

No se refiera implícitamente a un comentario de confirmación de otro.

351: pdr: Stop foo from grommiting.
352: pdr: Ooops, got that wrong, let's try again.
353: dan: New launch page.
354: pdr: Third time lucky.

Esa clase de cosas. No lo hagas Es muy tentador cuando te comprometes a menudo, porque recuerdas el compromiso que hiciste hace cinco minutos, y comentar comienza a parecer una conversación contigo mismo. Pero contrólate. No tiene sentido para la persona pobre, dos años después de su futuro, que busca el último compromiso en los archivos dados.