¿Cuándo realizar el trabajo en git?

7

Cuando estoy trabajando en un proyecto, tiendo a escribir muchos códigos. Un montón de código significa muchos errores. Si realizo mi trabajo desde el principio, tengo que editar ese compromiso cuando encuentro un error y lo soluciono. Es por eso que comencé a comprometerme al final del trabajo en el componente en el que estoy trabajando. Esto significa que podría hacer cambios sin el dolor de cabeza de corregir la confirmación previa.

Sin embargo, esto significa que tengo otro dolor de cabeza. Eso es dividir mi trabajo en partes más pequeñas para cometerlas por separado.

    
pregunta SloppyJoe 21.06.2016 - 10:53

3 respuestas

10

Al trabajar localmente, cometa cuando:

  • Usted agrega un nuevo caso de prueba.
  • Tus pruebas pasan.
  • Has hecho cualquier cambio que funcione, sin importar cuán insignificante sea.
    • ¿Ha cambiado el nombre de una variable? Cometerlo
    • ¿Extrajo un método? Cometerlo
    • ¿Se ha invertido una condición? Cometerlo
  • Básicamente, en cualquier momento el código se compila.

Luego, antes de enviarlo a un repositorio compartido, aplasta los compromisos en un solo cambio de trabajo.

Los beneficios aquí son que tiene un historial completo de cada cambio que realizó al trabajar en cualquier característica / corrección de errores en la que esté trabajando. Si te encuentras 3/4 terminado y te das cuenta de que necesitas volver a donde estabas 1/4 en el camino, está bien porque puedes . Aplastar antes de compartir el código garantiza que cada confirmación en el repositorio compartido representa un código de trabajo. Cualquiera puede retirar cualquier confirmación y aún tener un código de trabajo. Es bueno tener un historial limpio cuando SHTF y alguien necesitan revertir.

    
respondido por el RubberDuck 21.06.2016 - 12:45
4

Uno de los principios de Git es cometer temprano, cometer a menudo .

Desea comprometerse siempre que realice algún progreso tangible que no esté seguro de que lamentaría perder repentinamente.

Si cree que esto hace que su historial de git termine con demasiados compromisos sin sentido con mensajes de confirmación vagos, puede aplastar estos compromisos en uno antes de empujarlos a la rama principal usando git rebase .

    
respondido por el Philipp 21.06.2016 - 15:08
2
  

Es por eso que comencé a comprometerme al final del trabajo en el componente en el que estoy trabajando. Esto significa que podría hacer cambios sin el dolor de cabeza de corregir la confirmación anterior.

En mi opinión, esto puede ser un gran error si está trabajando en un equipo. Es un error particularmente grande cuando uno trabaja a tiempo parcial en la tarea A, a tiempo parcial en la tarea B, a tiempo parcial en la tarea C, etc. (mi vida), mientras que el resto del equipo está ardiendo. Es probable que tenga conflictos en abundancia al tratar de fusionar su trabajo en el proyecto general si espera unas semanas o más para asegurarse de que su código funciona perfectamente. (Aparte: tu código nunca es perfecto).

Es mucho mejor comprometerse localmente con mucha frecuencia y combinar el trabajo más grande en su sucursal con cierta frecuencia. En un proyecto en rápido movimiento, me comprometo varias veces al día y me fusiono una vez al día, como mínimo. Las fusiones frecuentes significan que puede hablar con la persona que escribió el código que rompió su código y tal vez llegar a un acuerdo. Las fusiones infrecuentes significan que los cambios que rompieron tu código probablemente están bloqueados.

Mi primer confirmación con respecto a alguna tarea es típicamente el pseudo código que compila (el pseudo código es casi todos los comentarios) pero falla todas las pruebas. Cuando abandone el proyecto A para trabajar en el proyecto B, me comprometo y me fusiono. Cuando vuelvo al proyecto A, lo primero que hago es colocar la rama de desarrollo en mi repositorio local y luego fusionarla en mi rama de función. Como resultado, rara vez veo conflictos.

  

Un montón de código significa muchos errores.

Eso no es necesariamente cierto. Lo que es cierto es que una gran cantidad de códigos no probados, no revisados y poco escritos significa muchos errores. Eso podría estar bien si lo que estás escribiendo es un código donde los errores no tienen mucho costo (pero eso también significa que no tiene mucho valor). Si está escribiendo un software en el que los errores pueden costar millones de dólares o incluso algo peor puede matar, simplemente no desea hacerlo. Existen técnicas, algunas antiguas, otras muy nuevas, que permiten escribir un código que está casi sin errores.

    
respondido por el David Hammen 21.06.2016 - 14:44

Lea otras preguntas en las etiquetas