Push Git rejeitado após rebase da ramificação de recurso

OK, achei que era um cenário simples, o que estou perdendo?

Eu tenho um masterramo e um featureramo. Faço alguns trabalhos master, outros featuree mais master. Termino com algo assim (ordem lexicográfica implica a ordem dos commits):

A--B--C------F--G  (master)
       \    
        D--E  (feature)

Não tenho nenhum problema para git push origin mastermanter o controle remoto masteratualizado, nem com git push origin feature(quando ativado feature) para manter um backup remoto para o meu featuretrabalho. Até agora, estamos bem.

Mas agora eu quero me refazer featuredos F--Gcommits no master, então eu git checkout featuree git rebase master. Ainda bom. Agora temos:

A--B--C------F--G  (master)
                 \
                  D'--E'  (feature)

Problema: no momento em que desejo fazer backup da nova featureramificação rebaseada git push origin feature, o push é rejeitado, pois a árvore foi alterada devido à rebasagem. Isso só pode ser resolvido com git push --force origin feature.

Eu odeio usar --forcesem ter certeza de que preciso. Então, eu preciso disso? O rebasing implica necessariamente que o próximo pushdeve ser --forcecumprido?

Esse ramo de recursos não é compartilhado com outros desenvolvedores; portanto, não tenho nenhum problema de fato com o impulso de força, não vou perder nenhum dado, a questão é mais conceitual.

O problema é que git pushassume que a ramificação remota pode ser encaminhada rapidamente para sua ramificação local, ou seja, que toda a diferença entre ramificações locais e remotas está no local, tendo alguns novos commit no final assim:

Z--X--R         <- origin/some-branch (can be fast-forwarded to Y commit)
       \        
        T--Y    <- some-branch

Quando você executa git rebaseconfirmações, D e E são aplicadas à nova base e novas confirmações são criadas. Isso significa que, após o rebase, você terá algo assim:

A--B--C------F--G--D'--E'   <- feature-branch
       \  
        D--E                <- origin/feature-branch

Nessa situação, a ramificação remota não pode ser encaminhada rapidamente para o local. Porém, teoricamente, a ramificação local pode ser mesclada em remota (obviamente você não precisa dela nesse caso), mas, como git pushexecuta apenas mesclagens de avanço rápido, lança e gera erros.

E o que a --forceopção faz é apenas ignorar o estado da ramificação remota e configurá-la para o commit que você está enviando. Então git push --force origin feature-branchsimplesmente substitui origin/feature-branchcom as autoridades locais feature-branch.

Na minha opinião, refazer a ramificação dos recursos mastere forçá-los a empurrá-los de volta para o repositório remoto é bom, desde que você seja o único que trabalha nesse ramo.

Em vez de usar -f ou --force, os desenvolvedores devem usar

--force-with-lease

Por quê? Porque ele verifica se há mudanças na ramificação remota, o que é absolutamente uma boa ideia. Vamos imaginar que James e Lisa estejam trabalhando no mesmo ramo de recursos e Lisa tenha enviado um commit. James agora repassa sua filial local e é rejeitado ao tentar empurrar. É claro que James acha que isso se deve à reformulação e uso do --force e reescreveria todas as alterações de Lisa. Se James tivesse usado --force-with-lease, ele teria recebido um aviso de que há compromissos feitos por outra pessoa. Não vejo por que alguém usaria --force em vez de --force-with-lease ao pressionar após uma rebase.

Eu usaria "checkout -b" e é mais fácil de entender.

git checkout myFeature
git rebase master
git push origin --delete myFeature
git push origin myFeature

Quando você exclui, evita enviar uma ramificação existente que contém SHA ID diferente. Estou excluindo apenas a ramificação remota neste caso.

Uma solução para isso é fazer o que é msysGit merge rebasing script faz - depois que o rebase, merge no antigo chefe da featurecom -s ours. Você acaba com o gráfico de confirmação:

A--B--C------F--G (master)
       \         \
        \         D'--E' (feature)
         \           /
          \       --
           \    /
            D--E (old-feature)

... e seu impulso featureserá um avanço rápido.

Em outras palavras, você pode fazer:

git checkout feature
git branch old-feature
git rebase master
git merge -s ours old-feature
git push origin feature

(Não testado, mas acho que está certo ...)

Pode ou não ser o caso de haver apenas um desenvolvedor neste ramo, que agora (após o rebase) não está alinhado com a origem / recurso.

Como tal, sugiro usar a seguinte sequência:

git rebase master
git checkout -b feature_branch_2
git push origin feature_branch_2

Sim, novo ramo, isso deve resolver isso sem uma força -, o que eu acho que geralmente é uma grande desvantagem do git.

Minha maneira de evitar o empurrão forçado é criar um novo ramo e continuar o trabalho nesse novo ramo e, após alguma estabilidade, remover o ramo antigo que foi rebatizado:

• Rebaseando a ramificação com check-out localmente
• Ramificação da ramificação rebased para uma nova ramificação
• Enviando esse ramo como um novo ramo para remoto. e excluir a ramificação antiga no controle remoto

Outros responderam sua pergunta. Se você refazer uma ramificação, precisará forçar a empurrá-la.

Rebase e um repositório compartilhado geralmente não se dão bem. Isso está reescrevendo o histórico. Se outras pessoas estiverem usando esse ramo ou se ramificarem nesse ramo, a recuperação será bastante desagradável.

Em geral, o rebase funciona bem para o gerenciamento de filiais locais. O gerenciamento de filial remota funciona melhor com mesclagens explícitas (--no-ff).

Também evitamos mesclar o mestre em um ramo de recurso. Em vez disso, redefinimos para master, mas com um novo nome de filial (por exemplo, adicionando um sufixo de versão). Isso evita o problema de rebasear no repositório compartilhado.

O que há de errado com um git merge masterno featureramo? Isso preservará o trabalho que você teve, mantendo-o separado da ramificação da linha principal.

A--B--C------F--G
       \         \
        D--E------H

Edit: Ah, desculpe, não leu sua declaração de problema. Você precisará de força ao executar a rebase. Todos os comandos que modificam o histórico precisarão do --forceargumento. Isso é à prova de falhas para impedir que você perca o trabalho (o antigo De Eseria perdido).

Portanto, você executou um git rebaseque fez a árvore parecer (embora parcialmente oculta De Enão esteja mais em um ramo nomeado):

A--B--C------F--G
       \         \
        D--E      D'--E'

Então, ao tentar empurrar seu novo featureramo (com D'e E'dentro dele), você perderia De E.

Para mim, seguir etapas fáceis funciona:

1. git checkout myFeature
2. git rebase master
3. git push --force-with-lease
4. git branch -f master HEAD
5. git checkout master
6. git pull

Depois de fazer tudo acima, podemos excluir o ramo myFeature também seguindo o comando:

git push origin --delete myFeature

O seguinte funciona para mim:

git push -f origin branch_name

e não remove nenhum código meu.

Mas, se você quiser evitar isso, faça o seguinte:

git checkout master
git pull --rebase
git checkout -b new_branch_name

então você pode escolher todos os seus commit no novo ramo. git cherry-pick COMMIT ID e depois empurre seu novo ramo.

Como o OP entende o problema, apenas procura uma solução melhor ...

Que tal isso como uma prática?

• Tenha um ramo de desenvolvimento de recursos real (onde você nunca se recupera e pressiona com força, para que seus colegas desenvolvedores de recursos não o odeiem). Aqui, pegue regularmente essas alterações do main com uma mesclagem. História mais confusa , sim, mas a vida é fácil e ninguém fica interrompido em seu trabalho.

• Tenha um segundo ramo de desenvolvimento de recursos, em que um membro da equipe de recursos regularmente empurra todos os recursos comprometidos para, de fato, reestruturados e até forçados. Tão quase limpo com base em um commit mestre bastante recente. Quando o recurso estiver concluído, empurre esse ramo em cima do mestre.

Talvez já exista um nome de padrão para esse método.