practices - “Git pull” o “git merge” entre las ramas maestra y de desarrollo

git workflow implementation

Question

Tengo mi rama master y una rama de develop para trabajar en algunos cambios. Necesito fusionar los cambios del master al develop , pero eventualmente fusionaré todo desde el develop al master . Tengo dos flujos de trabajo diferentes en mente:

1. git pull origin master en develop rama
2. git merge master en develop rama

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

Answer 1

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

Answer 2

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 de nuevo en 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

Answer 3

Si no está compartiendo la rama de desarrollo con nadie, entonces simplemente la volvería a actualizar cada vez que se actualice el maestro, de esa manera no tendrá compromisos de fusión en todo su historial 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 siempre estará al tanto de los últimos cambios de la rama maestra. Una vez que haya terminado con el desarrollo de rama y se actualice a los últimos cambios en el maestro, puede volver a fusionarlo:

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

Answer 4

Ten cuidado con la rebase. Si estás compartiendo tu rama de desarrollo con alguien, rebase puede hacer un lío de cosas. Rebase es bueno solo para sus propias sucursales locales.

Regla de oro, si ha empujado la rama a origen, no use rebase. En su lugar, utilice la combinación.

Answer 5

mi regla de oro es:

rebase para sucursales con el mismo nombre , merge otra manera.

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

Si el develop solo existe en el repositorio local, y siempre se basa en un origin/master confirmación de envío reciente, debe llamarlo master y trabajar allí directamente. simplifica tu vida y presenta las cosas tal como son en realidad: estás desarrollando directamente en la rama master .

si se comparte el develop , no se debe volver a basar en el master , simplemente fusionarlo de nuevo con --no-ff . Usted está desarrollando en develop . master y el develop tienen nombres diferentes, porque queremos que sean cosas diferentes y permanezcan separados. No los hagas iguales con rebase .