commit-pull-merge-push o pull-merge-commit-push?

Question

Empezamos a usar Mercurial hace varias semanas. La mayoría de los desarrolladores siguen este flujo de trabajo:

• trabajo sobre una característica
• commit -m "Se trabajó en función de la ABC"
• tirón -u
• Si rama
  • fusión
  • cometer - m "Fusionar"
  • empujar

Hoy en día, uno de nuestros desarrolladores sugirió que hacemos:

• trabajo sobre una característica
• tirón -u
• si rama
  • fusión
• commit -m "Funcionó en la función ABC"
• empuje

De esta manera, tenemos mucho menos "Merge" conjuntos de cambios en el registro.

Algunos de nosotros pensamos que es solo una cuestión de preferencia. Algunos de nosotros pensamos que uno es mejor que el otro. No tenemos mucha experiencia y no queremos vivir las desventajas del mal uso de la herramienta. Entonces, si un enfoque es más aconsejable que otro, por favor díganme por qué.

Answer 1

Me gusta más su procedimiento original, pero las personas razonables ciertamente pueden estar en desacuerdo. Considero fusionar una pieza real de trabajo de desarrollo de software y me gusta que sea un ciudadano de primera clase en nuestro proceso.

En su segundo/procedimiento sugerido, el riesgo es que la extracción hace algunas cosas que realmente no desea y luego le resulta muy difícil separarlo del trabajo que ya ha realizado.

Para las personas que no pueden soportar la historia rameado el flujo de trabajo preferido es habitual:

• trabajo sobre una característica
• cometer
• tirón --rebase
• empuje

donde aparece la opción --rebase en pull después de habilitar rebase extension. No soy partidario de rebase porque está técnicamente reescribiendo la historia, lo cual es antiético de cómo se supone que funciona mercurial, pero estoy en una minoría cada vez más reducida en ese punto.

En pocas palabras, si realmente no desea un historial detallado, use rebase - no actualice en cambios no confirmados ya que es difícil de deshacer.

Answer 2

Me gustaría ir con su primer flujo de trabajo. La objeción principal que tengo con la segunda opción es que si intenta fusionarse antes de comprometerse, no hay una forma fácil de evitar la combinación cuando las cosas van mal (lo que sucede de vez en cuando) para que pueda comenzar de nuevo.

Esto puede ser especialmente útil si obtienes un conflicto de combinación con la Característica A, y quieres preguntarle al desarrollador que trabajó en la Característica A algo al respecto, pero él está en su pausa para el almuerzo. Con su primer flujo de trabajo, puede cancelar la fusión y continuar hasta que el desarrollador vuelva y esté listo para fusionarse nuevamente. Con el segundo flujo de trabajo, simplemente te quedas atascado y tienes que buscar algo más que hacer (o hacer otro clon del repositorio y trabajar en ese hasta que puedas fusionar, pero eso me parece peor).

Answer 3

Esto no funcionará:

• trabajo sobre una característica
• tirón -u
• si rama
  • fusión
• commit -m "Se trabajó en función ABC "
• push

Si tiene cambios locales, no puede fusionarse. Lo que/puede/hacer es lo siguiente:

• trabajo sobre una característica
• tirón -u
• trabajo sobre una característica
• tirón -u
• trabajo sobre una característica
• tirón - u
• ...
• commit -m "Se trabajó en función de la ABC"
• push

Es posible que también desee investigar hg fetch, se envía con el complemento opcional mercurial que realiza el pull/merge en el mismo paso. Lo cual es bueno si olvidó tirar antes de comprometerse.