¿Se recomienda git rebase mientras varios desarrolladores trabajan en la misma twig?

En http://git-scm.com/book/es/Git-Branching-Rebasing#The-Perils-of-Rebasing

Se recomienda que el rebasamiento no se realice cuando el repository sea público.

Y una publicación reciente en git merge vs rebasing

recomienda que la rebase no se realice en la twig compartida entre desarrolladores.

Entiendo que, debido a que un desarrollador podría fusionar primero el código y luego decide volver a establecer la base del código, otros desarrolladores podrían terminar creando múltiples commits duplicates como se explica en Perils of Rebasing.

¿Qué pasa si todos los desarrolladores llegan a un acuerdo común de que todo el mundo siempre va a volver a establecer el código en lugar de fusionarse? ¿La recomendación todavía se aplica?

PD

Todas estas respuestas me confunden. De espesor voy a replantear la pregunta de nuevo.

Supongamos que hay dos desarrolladores trabajando en dos computadoras diferentes. Hay un repository central Los dos desarrolladores clonaron y comenzaron a trabajar.

Desarrollador 1:

  • Creó una twig de local / master. Digamos local / iss123.
  • Lo empujó a control remoto

Desarrollador 2:

  • Tiró de los cambios desde el control remoto
  • cheque a local / iss123
  • Se realizaron algunas confirmaciones en local / iss123
  • Empujó los cambios a control remoto / iss123

Desarrollador 1:

  • Tiene algunos compromisos locales
  • Él quiere rebasear la sucursal con origen / iss123
  • git rebase origen / iss123
  • Luego empuja sus commits a origen / iss123

Desarrollador 2:

  • Tiene algunos compromisos locales
  • Rebase la twig con origen / iss123
  • git rebase origen / iss123

y así. Siempre el desarrollador 1 y 2 volverá a establecer la base de su twig con origen / twig y luego empujará sus cambios al origen / twig

Después de que la funcionalidad es estable, finalmente

Desarrollador 1:

  • pagos a locales / maestros
  • extrae el último código de origen / maestro
  • comtesting si hay algún commit en local / master de otros desarrolladores
  • pagará a local / iss123
  • volverá a la base local / iss123 con local / master si hay nuevas confirmaciones.
  • Luego empuja la twig local / iss123 a remote / iss123 si hay una rebase hecha.
  • Luego comtesting a local / maestro
  • fusiona local / iss123 en local / master
  • Luego empuja local / master al origen / master

Desarrollador 2:

  • Ahora extraerá los últimos cambios de origen / maestro y origen / iss123 a local / principal y local / iss123 respectivamente

Más tarde el ciclo continúa de nuevo.

¿Es esto correcto? ¿Es esta la manera correcta cuando dos desarrolladores trabajan en la misma twig y siempre quieren volver a establecer la database en lugar de fusionarse?

Supongamos que nadie hace una rebase interactiva, cambiando el historial, sino que simplemente hace una git fetch y luego una git rebase origin/branch . En ese caso, podrías hacer un push, si nadie más ha empujado su rebase reciente, de lo contrario tendrás conflictos y tendrás que volver a establecer la base una vez más. Lo importante es que todo el mundo es diligente en el rebasamiento y nunca hace un push -f , ya que eso causará problemas para todos los push -f posteriores.

La pregunta, sin embargo, es por qué querrías hacer esto. Si el objective es solo evitar confusiones de fusión, sería mejor con un flujo de trabajo como este:

  1. Rama fuera de la twig común
  2. Haz tu trabajo
  3. Rebase su twig personal contra la twig común (en caso de que alguien más haya cometido algo
  4. empuje su twig contra la twig común
  5. si la inserción falla debido a un conflicto, vaya al paso 3
  6. Comience de nuevo en uno para el siguiente elemento de trabajo

De esta forma, todos siempre comprometen su trabajo como compromisos lineales en la parte superior de la twig común.

Nota: Dejar mi respuesta original, pero agregar algo más de información basada en la pregunta actualizada.

Básicamente, mi recomendación sería que los desarrolladores que trabajan en local/iss123 continúen fusionándose los cambios a medida que van y vienen a través de git pull . Una vez que iss123 es estable, uno de los desarrolladores lo volverá a convertir en maestro, es decir,

 git checkout iss123 git checkout -b rebase_iss123 git rebase -i master // select first as edit (so you can change its commit message) // and select the rest as fixup git checkout master git merge rebase_iss123 

Esto tomará todo iss123 y lo comprimirá en una única confirmación en la queue del maestro.

Ahora los desarrolladores pueden ramificar el nuevo trabajo de ese maestro.

Una vez que el código se envía a un repository público, no debe haber ningún cambio en las confirmaciones. Pero al volver a basar en su repository local, presionar es search. Ejemplo: realizo cambios en una twig de características. Luego tomo de la twig principal de mi twig de características, generalmente desarrollo una twig. Luego puedo volver a establecer la base de mi twig de características en el desarrollo. Entonces puedo empujar mi twig de desarrollo al origen.

Por lo tanto, si todos los desarrolladores reinician en sus repositorys locales, entonces la rebase luego presionarlo estará bien.

El punto principal es que una vez que se ha compartido un compromiso o una sucursal en un repository público, nadie puede cambiar hacer una rebase o modificar un comentario, etc.