git-merge nuevo - Melhor(e mais segura)maneira de mesclar um git branch em master



github commit (8)

Eu usaria o método de rebase. Principalmente porque reflete perfeitamente seu caso semanticamente, ie. O que você quer fazer é atualizar o estado do seu ramo atual e "fingir" como se fosse baseado no mais recente.

Então, mesmo sem verificar o master , eu gostaria de:

git fetch origin
git rebase -i origin/master
# ...solve possible conflicts here

É claro que buscar a origem não atualiza o estado local do seu master (pois não realiza uma mesclagem), mas é perfeitamente aceitável para nosso propósito - queremos evitar a mudança, para economizar tempo.

Uma nova ramificação do master é criada, chamamos de test .

Existem vários desenvolvedores que se comprometem a master ou criar outras ramificações e depois se fundem no master .

Digamos que o trabalho no test esteja demorando vários dias e você deseja manter continuamente o test atualizado com os commits dentro do master .

Eu faria git pull origin master do test .

Pergunta 1: Essa é a abordagem correta? Outros desenvolvedores poderiam ter trabalhado facilmente nos mesmos arquivos que eu trabalhei btw.

Meu trabalho no test está pronto e estou pronto para mesclar de volta ao master . Aqui estão as duas maneiras em que posso pensar:

UMA:

git checkout test
git pull origin master
git push origin test
git checkout master
git pull origin test 

B:

git checkout test
git pull origin master
git checkout master
git merge test

Eu não estou usando --rebase porque do meu entendimento, o rebase irá obter as mudanças do master e empilhar o meu em cima disso, portanto, pode sobrescrever as alterações feitas por outras pessoas.

Pergunta 2: Qual desses dois métodos está correto? Qual a diferença aí?

O objetivo de tudo isso é manter meu branch de test atualizado com as coisas que estão acontecendo no master e depois eu poderia mesclá-lo de volta ao master esperando manter a linha do tempo o mais linear possível.


git checkout master
git pull origin master
# Merge branch test into master
git merge test

Após a mesclagem, se o arquivo for alterado, quando você mesclá-lo será através do erro "Resolver Conflito"

Então você precisa primeiro resolver todos os seus conflitos então, você tem que comprometer novamente todas as suas mudanças e então empurrar

git push origin master

É melhor fazer quem fez mudanças no ramo de teste, porque ele sabia que mudanças ele fez.


Esse é o fluxo de trabalho que uso no meu trabalho com a equipe. O cenário é como você descreveu. Primeiro, quando eu terminar de trabalhar no test eu rebaso com o mestre para puxar o que foi adicionado ao master durante o tempo em que estive trabalhando no branch de test .

git pull -r upstream master

Isto irá puxar as mudanças para o master desde que você bifurcou o branch de test e as aplicou, e então aplicará as mudanças que você fez para testar "em cima" do estado atual do master. Pode haver conflitos aqui, se as outras pessoas tiverem feito alterações nos mesmos arquivos que você editou no teste. Se houver, você terá que corrigi-los manualmente e confirmar. Uma vez feito isso, você será bom para mudar para o branch master e mesclar o test sem problemas.


Eu primeiro faria a ramificação to be ser mesclada o mais limpa possível. Execute seus testes, verifique se o estado é o desejado. Limpe os novos commits pelo git squash .

Além da resposta da KingCrunches , sugiro usar

git checkout master
git pull origin master
git merge --squash test
git commit
git push origin master

Você pode ter feito muitos commits no outro branch, que deve ser apenas um commit no master branch. Para manter o histórico de commit o mais limpo possível, você pode querer esmagar todos os seus commits do branch de teste em um commit no branch master (veja também: Git: To squash or not squash? ). Então você também pode reescrever a mensagem de commit para algo muito expressivo. Algo que é fácil de ler e entender, sem entrar no código.

edit: você pode estar interessado em

Então, no GitHub, eu acabei fazendo o seguinte para uma ramificação de recurso mybranch :

Receba as últimas da origem

$ git checkout master
$ git pull origin master

Encontre o hash da base de mesclagem:

$ git merge-base mybranch master
c193ea5e11f5699ae1f58b5b7029d1097395196f

$ git checkout mybranch
$ git rebase -i c193ea5e11f5699ae1f58b5b7029d1097395196f

Agora, certifique-se apenas o primeiro é pick , o resto é s :

pick 00f1e76 Add first draft of the Pflichtenheft
s d1c84b6 Update to two class problem
s 7486cd8 Explain steps better

Em seguida, escolha uma mensagem de commit muito boa e pressione para o GitHub. Faça o pedido de puxar então.

Após a mesclagem da solicitação pull, você pode excluí-la localmente:

$ git branch -d mybranch

e no GitHub

$ git push origin :mybranch

Como eu faria isso

git checkout master
git pull origin master
git merge test
git push origin master

Se eu tenho um ramo local de um remoto, não me sinto confortável com a fusão de outros ramos do que este com o controle remoto. Além disso, eu não iria empurrar as minhas alterações, até que eu esteja feliz com o que eu quero empurrar e também eu não iria empurrar as coisas em tudo, que são apenas para mim e meu repositório local. Na sua descrição, parece que esse test é só para você? Então, não há razão para publicá-lo.

git sempre tenta respeitar as suas e outras mudanças, e assim vai --rebase . Eu não acho que eu possa explicar isso apropriadamente, então dê uma olhada no livro do Git - Rebasing ou git-ready: Intro no rebasing para uma pequena descrição. É um recurso bem legal


Esta é uma questão muito prática, mas todas as respostas acima não são práticas.

Gostar

git checkout master
git pull origin master
git merge test
git push origin master

Essa abordagem tem dois problemas :

  1. Não é seguro, porque não sabemos se há algum conflito entre o branch de teste e o branch master.

  2. Seria "apertar" todos os commits de teste em um commit de merge no master; isto é, no branch master, não podemos ver todos os logs de alteração do branch de teste.

Então, quando suspeitamos que haveria alguns conflitos, podemos ter as seguintes operações do git:

git checkout test
git pull 
git checkout master
git pull
git merge --no-ff --no-commit test

Teste a merge antes de commit , evite um avanço rápido por --no-ff ,

Se um conflito for encontrado, podemos executar o git status para verificar detalhes sobre os conflitos e tentar resolver

git status

Uma vez que resolvemos os conflitos, ou se não há conflito, nos commit e os push

git commit -m 'merge test branch'
git push

Porém, desta forma, perderá o histórico de alterações registrado na ramificação de teste e tornaria difícil a ramificação principal para outros desenvolvedores entenderem a história do projeto.

Então, o melhor método é usar rebase vez de merge (suponha que, nesse tempo, tenhamos resolvido os conflitos de ramificação).

A seguir, uma amostra simples, para operações avançadas, consulte http://git-scm.com/book/en/v2/Git-Branching-Rebasing

git checkout master
git pull
git checkout test
git pull
git rebase -i master
git checkout master
git merge test

Sim, quando você tiver feito os uppers, todos os commits do branch Test serão movidos para a cabeça do branch Master. O principal benefício da rebasing é que você obtém um histórico de projeto linear e muito mais limpo.

A única coisa que você precisa evitar é: nunca use rebase em branch público, como branch master.

Nunca faça operações como as seguintes:

git checkout master
git rebase -i test

Detalhes para https://www.atlassian.com/git/tutorials/merging-vs-rebasing/the-golden-rule-of-rebasing

apêndice:


Tópico antigo, mas não encontrei meu jeito de fazer isso. Pode ser valioso para alguém que trabalha com rebase e quer mesclar todos os commits de um branch no topo do master. Se houver um conflito no caminho, você poderá resolvê-los para cada commit.

Obter Master e Branch atualizados:

git checkout master
git pull --rebase origin master
git checkout <branch_name>
git pull --rebase origin <branch_name>

Merge Branch no topo do Master:

git checkout <branch_name>
git rebase master
git add .
git rebase continue

Se você se deparar com Conflitos durante o Rebase:

Primeiro, resolva o conflito no arquivo. Então:

git add .
git rebase --continue

Quando o rebase terminar, rebate a ramificação no topo do master:

git checkout master
git rebase <branch_name>

Isso não "move" eles no sentido técnico, mas tem o mesmo efeito:

A--B--C  (branch-foo)
 \    ^-- I wanted them here!
  \
   D--E--F--G  (branch-bar)
      ^--^--^-- Opps wrong branch!

While on branch-bar:
$ git reset --hard D # remember the SHAs for E, F, G (or E and G for a range)

A--B--C  (branch-foo)
 \
  \
   D-(E--F--G) detached
   ^-- (branch-bar)

Switch to branch-foo
$ git cherry-pick E..G

A--B--C--E'--F'--G' (branch-foo)
 \   E--F--G detached (This can be ignored)
  \ /
   D--H--I (branch-bar)

Now you won't need to worry about the detached branch because it is basically
like they are in the trash can waiting for the day it gets garbage collected.
Eventually some time in the far future it will look like:

A--B--C--E'--F'--G'--L--M--N--... (branch-foo)
 \
  \
   D--H--I--J--K--.... (branch-bar)




git git-merge