"Git pull" ou "git merge" entre os ramos mestre e de desenvolvimento

243

Eu tenho minha masterfilial e uma developfilial para trabalhar em algumas alterações. Preciso mesclar alterações de masterem develop, mas acabarei mesclando tudo de developem master. Eu tenho dois fluxos de trabalho diferentes em mente:

git pull origin masterno developramo
git merge masterno developramo

Qual é a melhor maneira de fazer isso e por quê?

git workflow

— Carson
fonte

18

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

— Alex Brasetvik

2

git pull= git fetch+git merge FETCH_HEAD

— Yousha Aleayoub

104

Tenha cuidado com a rebase. Se você estiver compartilhando sua ramificação de desenvolvimento com alguém, o rebase pode fazer uma bagunça. Rebase é bom apenas para suas próprias filiais locais.

Como regra geral, se você empurrou o ramo para a origem, não use rebase. Em vez disso, use mesclagem.

— Eric Leads
fonte

No entanto, é seguro fazer uma nova recuperação e um git push origin rebasedBranch --forcerepo privado? O único usuário sou eu mesmo.

— K0pernikus 25/10/12

Sim, se você é o único usuário, é claro que é seguro. Eu uso o git push --force o tempo todo quando sou o único usuário. :)

— Tyler Rick

3

Eu ecoo o aviso de Eric. Embora seja perfeitamente aceitável refazer sua própria ramificação remota. Brinque com rebase e mesclagem e você entenderá os prós e contras de cada um e aprenderá quando usá-los.

— Ian Lotinsky

Bom artigo sobre o uso de rebase, mesmo fundindo depois de resolver conflitos: github.com/everpix/Everpix-Intelligence

— Ian Lotinsky

@IanLotinsky, seu link não aponta para um artigo sobre rebase. Longshot, mas você ainda tem o link correto? :)

— Daniel Serodio

347

Esse fluxo de trabalho funciona melhor para mim:

git checkout -b develop

... faça algumas alterações ...

... o mestre de avisos foi atualizado ...

... comprometer alterações para desenvolver ...

git checkout master
git pull

... trazer essas mudanças de volta ao desenvolvimento ...

git checkout develop
git rebase master

... faça mais algumas alterações ...

... comprometa-os a desenvolver ...

... fundi-los em mestre ...

git checkout master
git pull
git merge develop

— Ian Lotinsky
fonte

2

É assim que eu também trabalho, e acho que funciona bem. Há uma coisa que eu não faço, e é a git pulldireita antes da final git merge develop. Qual é o propósito disso?

— Crdx 31/08/12

Após a atualização do ... mestre de notificações ... parte, o mestre de checkout não limparia suas alterações locais para desenvolver se você não as confirmar?

— a1an

1

@ a1an Não, mas se você não as confirmar, as alterações passarão para o ramo principal e o git não permitirá que você puxe até que elas tenham sido confirmadas.

— elemjay19

5

@crdx As chances são de que outras ramificações sejam mescladas ao mestre remoto antes de você mesclar o seu ramo ao mestre local. Você puxa e traz as alterações do mestre remoto para sua cópia local do mestre. Foi assim que eu entendi.

— Tarun

12

git pull --rebase origin masterno seu ramo de desenvolvimento é um pouco mais rápido.

— Nathan Lilienthal

24

A melhor abordagem para esse tipo de coisa é provavelmente git rebase. Ele permite que você puxe as alterações do master para o seu ramo de desenvolvimento, mas deixe todo o seu trabalho de desenvolvimento "em cima" (posteriormente no log de confirmação) do material do master. Quando seu novo trabalho estiver concluído, a mesclagem de volta ao mestre será muito simples.

— divegeek
fonte

10

Um bom conselho, supondo que developnão seja compartilhado com mais ninguém.

— 22811 Karl Bielefeldt

1

@KarlBielefeldt Se develop for compartilhado com outros colaboradores, como atualizaremos developquando alguns hotfixes forem enviados diretamente para master? Devemos fazer uma fusão, ou seja git checkout master && git pull --rebase && git checkout develop && git merge master? Deixei um comentário sobre a resposta mais votada acima, que também detalha essa preocupação.

— Modulitos

5

Se você não está compartilhando o branch de desenvolvimento com ninguém, então eu o refizeria toda vez que o mestre fosse atualizado, dessa forma você não terá commits de mesclagem em todo o seu histórico, uma vez que você irá mesclar o master novamente. O fluxo de trabalho nesse caso seria o seguinte:

> 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

As etapas acima garantirão que sua ramificação de desenvolvimento esteja sempre em cima das alterações mais recentes da ramificação principal. Depois de concluir o branch de desenvolvimento e ele ser refeito para as alterações mais recentes no master, basta mesclar novamente:

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

— KiRPiCH
fonte

1

minha regra de ouro é:

rebasepara ramos com o mesmo nome , mergecaso contrário.

exemplos para os mesmos nomes seriam master, origin/mastere otherRemote/master.

se developexiste apenas no repositório local e é sempre baseado em uma origin/masterconfirmação recente , você deve chamá-lo mastere trabalhar diretamente nele. simplifica sua vida e apresenta as coisas como elas realmente são: você está desenvolvendo diretamente no masterramo.

se developfor compartilhado, não deverá ser refazido master, apenas mesclado novamente --no-ff. você está desenvolvendo develop. mastere developtêm nomes diferentes, porque queremos que sejam coisas diferentes e fiquem separados. não os faça iguais rebase.

— hoijui
fonte