"Git pull" o "git merge" entre las ramas maestra y de desarrollo

243

Tengo mi mastersucursal y una developsucursal para trabajar en algunos cambios. Necesito fusionar los cambios desde masterdentro develop, pero eventualmente fusionaré todo desde developdentro master. Tengo dos flujos de trabajo diferentes en mente:

git pull origin masteren developrama
git merge masteren developrama

¿Cuál es la mejor manera de hacer esto y por qué?

git workflow

— Carson
fuente

18

Lectura recomendada: nvie.com/posts/a-successful-git-branching-model

— Alex Brasetvik

2

git pull= git fetch+git merge FETCH_HEAD

— Yousha Aleayoub

104

Ten cuidado con rebase. Si está compartiendo su rama de desarrollo con alguien, rebase puede hacer un desastre. Rebase es bueno solo para sus propias sucursales locales.

Como regla general, si ha empujado la rama al origen, no use rebase. En su lugar, use merge.

— Eric lleva
fuente

Sin embargo, ¿es seguro rebase y un git push origin rebasedBranch --forcerepositorio privado? El único usuario soy yo.

— k0pernikus

Sí, si eres el único usuario, por supuesto, es seguro. Uso git push --force todo el tiempo cuando soy el único usuario. :)

— Tyler Rick

3

Me hago eco de la advertencia de Eric. Sin embargo, también está perfectamente bien cambiar la base de su propia rama remota. Juegue con rebase y fusión y comprenderá los pros y los contras de cada uno y aprenderá cuándo usarlos.

— Ian Lotinsky

Buen artículo sobre el uso de rebase, incluso fusionándose después de resolver conflictos: github.com/everpix/Everpix-Intelligence

— Ian Lotinsky

@IanLotinsky su enlace no apunta a un artículo sobre rebase. Tiro largo, pero ¿todavía tienes el enlace correcto? :)

— Daniel Serodio

347

Este flujo de trabajo funciona mejor para mí:

git checkout -b develop

... hacer algunos cambios ...

... aviso maestro ha sido actualizado ...

... cometer cambios para desarrollar ...

git checkout master
git pull

... traer esos cambios nuevamente al desarrollo ...

git checkout develop
git rebase master

... hacer algunos cambios más ...

... comprometerlos a desarrollar ...

... fusionarlos en maestro ...

git checkout master
git pull
git merge develop

— Ian Lotinsky
fuente

2

Así es como yo también trabajo, y creo que funciona bien. Sin embargo, hay una cosa que no hago, y es git pulljusto antes de la final git merge develop. ¿Cuál es el propósito de eso?

— crdx

Después de que ... el maestro de avisos se haya actualizado ..., ¿no eliminaría el maestro de pago sus cambios locales para desarrollarlos si no los confirma?

— a1an

1

@ a1an No, pero si no los confirma, los cambios se moverán a la rama maestra y git no le permitirá retirarlos hasta que se hayan confirmado.

— elemjay19

55

@crdx Lo más probable es que otras ramas se fusionen con el maestro remoto antes de que combine su rama con su maestro local. Usted tira y trae cambios maestros remotos a su copia local del maestro. Así es como lo entendí.

— Tarun

12

git pull --rebase origin masteren su rama de desarrollo es un poco más rápido.

— Nathan Lilienthal

24

El mejor enfoque para este tipo de cosas es probablemente git rebase. Le permite extraer cambios del maestro en su rama de desarrollo, pero dejar todo su trabajo de desarrollo "encima" (más adelante en el registro de confirmación) del material del maestro. Cuando se completa su nuevo trabajo, la fusión de nuevo al maestro es muy sencilla.

— Divegeek
fuente

10

Un buen consejo, suponiendo developque no se comparta con nadie más.

— Karl Bielefeldt

1

@KarlBielefeldt Si develop se comparte con otros contribuyentes, ¿cómo actualizaríamos developcuando se introdujeran directamente algunas revisiones master? ¿Deberíamos hacer una fusión, es decir git checkout master && git pull --rebase && git checkout develop && git merge master? Dejé un comentario sobre la respuesta más votada arriba, que también detalla esta preocupación.

— modulitos

5

Si no está compartiendo la sucursal de desarrollo con nadie, entonces simplemente la cambiaría cada vez que se actualice master, de esa manera no tendrá compromisos de fusión en toda su historia una vez que fusione el desarrollo en maestro. El flujo de trabajo en este caso sería el siguiente:

> git clone git://<remote_repo_path>/ <local_repo>
> cd <local_repo>
> git checkout -b develop
....do a lot of work on develop
....do all the commits
> git pull origin master
> git rebase master develop

Los pasos anteriores asegurarán que su rama de desarrollo estará siempre al tanto de los últimos cambios de la rama maestra. Una vez que haya terminado con la rama de desarrollo y se haya modificado con los últimos cambios en el maestro, puede fusionarlo nuevamente:

> git checkout -b master
> git merge develop
> git branch -d develop

— KiRPiCH
fuente

1

mi regla de oro es:

rebasepara ramas con el mismo nombre , de lo mergecontrario.

ejemplos para los mismos nombres serían master, origin/mastery otherRemote/master.

si developexiste solo en el repositorio local y siempre se basa en una origin/masterconfirmación reciente , debe llamarlo mastery trabajar allí directamente. simplifica tu vida y presenta las cosas como realmente son: estás desarrollándote directamente en la masterrama.

si developse comparte, no debe volver a basarse en él master, solo fusionarse con él --no-ff. está desarrollando en develop. mastery developtienen nombres diferentes, porque queremos que sean cosas diferentes y que se mantengan separadas. no los hagas igual con rebase.

— hoijui
fuente