Reutilizando una twig de desarrollo fusionada / Remerging en una twig estable sin cambios con git

Dos progtwigdores, A & B, están trabajando en un proyecto con un repository hospedado de github:

Maestro de twig existe.

El progtwigdor A crea devBranchA basado en el último maestro

master$ git checkout -b devBranchA 

El progtwigdor B crea devBranchB basado en el último maestro

 master$ git checkout -b devBranchB 

Deciden fusionar los cambios estables en maestros siempre que sea posible.

El flujo de trabajo acordado es:

[en devBranch]

 git commit -m 'Stuff to make branch stable enough to merge' git checkout master git pull origin master git merge devBranch [fix merge conflicts if any] git checkout devBranch git commit -m 'New cool stuff' 

Sin embargo, si no ha habido commits para master desde la última fusión, entonces no es posible fusionar el devbranch nuevamente en master (a less que se haya creado una nueva twig dev, en lugar de la anterior reutilizada)

En este caso, cuando el Progtwigdor B viene a fusionar su trabajo en la twig principal, no será el maestro previsto actual, sino el estado del maestro antes de la fusión.

¿Hay alguna forma de obligar automáticamente a la twig principal a actualizarse al jefe de la twig de desarrollo en la fusión si no ha habido confirmaciones intermedias?

¿Cuál es el flujo de trabajo multiusuario previsto cuando se trabaja con git y un repository de github centralizado? Siento que no estoy usando git ya que está destinado a ser utilizado.

Echa un vistazo a git fetch;git rebase origin/master o git pull --rebase , ambos git pull --rebase el order de los commits en el repository principal porque rebases, pegando local commits en la parte superior. No importa el order de las confirmaciones locales tanto en las sucursales locales porque solo tú las tienes. Pruébelo, pero úselo con cuidado, por ejemplo, duplique una twig antes de volver a basarla hasta que esté acostumbrado.

En general, estás hablando del flujo de trabajo de git, y descubrí que hay dos flujos de trabajo generales con los que debes familiarizarte. Tenga en count que estoy hablando de mi experiencia personal sobre cómo minimizar los conflictos:

  • Flujo de trabajo de primera base (para get el historial de compromiso más limpio, empuja la carga de los conflictos en general al código no asignado)
  • Flujo de trabajo de combinación (a veces más simple cuando hay muchos cambios que podrían entrar en conflicto, normalmente lo uso solo como alternativa)

Ejemplo de flujo de trabajo inicial

 git checkout master // For the sake of argument, let's say the latest commit in your local master is from august 1st or something old like that. git branch temp_branch // copy of the master git checkout temp_branch git add changedFiles;git commit changedFiles; // A change from november 2nd. git log // Now your dev branch has a new commit on top of an otherwise old branch. git log origin/master // You get a listing of the commits from the origin repository, the master branch. 

En general, utilizo Origin / Master para el desarrollo de etapas, con las tags git para las confirmaciones que se realizan en vivo.

Ahora aquí es donde ocurre el problema, y ​​donde la elección del flujo de trabajo entra en juego: digamos que hay un compromiso que proviene de otro repository de desarrollo en el maestro, por ejemplo, un compromiso desde el 15 de octubre. Tal vez fue cometido por otro desarrollador, tal vez por ti mismo.

Tus elecciones: fusionar o rebasear.

Unir

Presenta un compromiso adicional, respeta el historial de desarrollo de sucursal local (no distribuido) sobre la historia canónica (origen / maestro), causa un poco más de potencial de conflictos para otros y otras twigs . En esencia, estás diciendo "mi pedido de compromiso se combinará con la order de compromiso de la sucursal maestra" en lugar de reorderar el historial de compromiso.

 git merge origin/master // merge commit introduced ... // Resolve any conflicts, and finalize the merge commit. git checkout master;git rebase temp_branch // Move the changes to master. git push origin/master // Pushing changes, including merge commit, to origin/master 

Al final, el historial de commit se verá algo así como: agosto-octubre-noviembre-MergeCommit

Rebase

Sin compromisos adicionales, los honores ya se comprometen en el repository canónico (origen / máster) sobre los compromisos locales, los conflictos que se producen generalmente se producen en confirmaciones que el desarrollador aún no ha comprometido (y por lo tanto nadie más puede contabilizar).

 git rebase origin/master // ... // Resolve any conflicts... git rebase --continue or git rebase --abort ... // Resolve any conflicts... git checkout master;git rebase temp_branch // Get the branch changes without a merge commit into master. git push // Push all changes to the canonical repository. 

Nota: Si terminas teniendo que hacer más de dos resoluciones de conflictos, entonces es un buen momento para git rebase --abort y hacer una fusión.


Pruebe el process, vea si tiene sentido para usted. Toma un poco de experimentación antes de que puedas get tácticas que funcionen bien para tu desarrollo en git, supongo que porque hay muchos más enfoques una vez que te descentralizas.

Puede encontrar otra ilustración de los dos flujos de trabajo mencionados por Tchalvak en su respuesta en " git rebase vs git merge ".

Como se explica en " ¿Cuál es el flujo de trabajo de git correcto con twigs de funciones compartidas? ", Prefiero evitar "fusión devBranch " (de master a devBranch ), y preferiría volver a establecer la devBranch datos de devBranch sobre el master , siempre que:

  • devBranch se fusiona regularmente para dominar
  • Rebase solo las nuevas confirmaciones locales (que aún no he enviado).