git: fusionarse con una twig remota actualizada frecuentemente?

Solo me pregunto cuál es la práctica habitual para volver a fusionar con el maestro, cuando es probable que HEAD se haya actualizado nuevamente desde la última extracción antes de la fusión. Para ilustrar, en el siguiente diagtwig, M es el punto de fusión deseado, pero como el HEAD maestro se actualiza a A1 para el momento en que M se confirma y está listo para ser empujado, M1 se convertirá en el nuevo punto de fusión deseado, en otras palabras, una nueva fusión tiene que ser intentado.

master-----A----A1---... \ \ M M1 / / local------B------ 

Tenga en count que preferiría no fusionar M y A1 porque podría haber A2, A3 en la línea y si el problema vuelve a aparecer, me parece demasiado desorderado con fusiones no intencionadas adicionales. Si los cambios en el nivel local son suficientemente independientes de los del maestro, a veces solo volvería a basarlos en el maestro, lo que me parece una solución más fácil. Pero en otras ocasiones realmente espero que haya alguna manera de "reutilizar" el trabajo de fusión que hice para M, para M1.

Digamos que cada persona en el equipo mantiene su propio repository. Una sola persona en el equipo mantiene lo que se conoce colectivamente como el repository main .

A medida que los miembros del equipo trabajan, pueden retirarse del main pero no presionan al main. Durante una extracción, si hay un conflicto de fusión, esa persona corregirá su propio código.

Ahora el propietario de las necesidades main al less lee el acceso al repository de cada miembro. El propietario de main luego tira de cada repository por turno. Si no hay conflictos de fusión, no hay problema. Si hay un conflicto, el propietario de main aborta el commit, y la persona que posee el código soluciona el conflicto. Repasemos esta parte en detalle

  1. main tiradas de bob – ok; la fusión se completa y se publica
  2. tiradas main de tom – conflicto; la fusión es abortada
  3. el propietario de main le dice a tom que saque los últimos cambios y arregle el conflicto
  4. tom puede arreglar el conflicto él mismo, luego dile a main que intente de nuevo
  5. main tiradas de tom – ok

Este process se repite todos los días, o por muy a menudo que sea su ciclo de integración.

Si bien definitivamente le impone la carga a una sola persona, esa persona no tiene que arreglar ninguno de los conflictos, es un trabajo que podría automatizarse si se tiene la motivación adecuada. Así es como Linus lo hace para administrar el kernel.

Usamos un token de check-in para coordinar este tipo de problema. Quien lo tenga, tiene la security de que nadie más se registrará en el maestro hasta que se libere.

Si estás en el mismo lugar que los otros desarrolladores que se registran en la cabeza, entonces usa una ficha física (un elefante / mono / pollo: cualquier cosa, más lindo, mejor).

Cuando hemos tenido desarrollo distribuido, hemos utilizado una página wiki con una tabla donde la parte superior es la persona con el "token".

Parece un trabajo para git rebase .

Flujo de trabajo

Estás trabajando en una sucursal separada (llamémosla local ) y haces algunos commits. Cuando esté listo para impulsar sus cambios, revise la twig master y realice un git pull . Verifica tu sucursal local y haz un git rebase master . Este command:

  1. deja de lado tus cambios / compromisos (en local ) ya que el master y el local han separado,
  2. hacer una fusión de avance rápido con la twig master ,
  3. vuelva a comprometer sus cambios originales en la sucursal local. Tenga en count que el post, el autor y la date de la confirmación siguen siendo los mismos, PERO la confirmación hash CAMBIA . Esto sucede porque todos los objects (commits, trees, blobs) son inmutables y dado que la propiedad primaria de la confirmación cambia, git creará otra confirmación.

Implicaciones de git rebase

Como el hash de confirmación cambia, debe hacer la rebase solo en las twigs LOCALES (es decir, que NO se envíen a control remoto).

Finalmente me di count de lo que tenía en mente exactamente, y la solución es simplemente volver a establecer la confluencia de la fusión como se describe aquí: Reasignación de un compromiso de fusión Git