Reestruturando ramificações remotas no Git

Estou usando um repositório Git intermediário para espelhar um repositório SVN remoto, no qual as pessoas podem clonar e trabalhar. O repositório intermediário tem sua ramificação principal rebatida todas as noites a partir do SVN upstream, e estamos trabalhando nas ramificações de recursos. Por exemplo:

remote:
  master

local:
  master
  feature

Posso enviar com êxito minha ramificação de recursos de volta ao controle remoto e terminar com o que espero:

remote:
  master
  feature

local:
  master
  feature

Em seguida, reconfiguro a ramificação para rastrear o controle remoto:

remote:
  master
  feature

local:
  master
  feature -> origin/feature

E está tudo bem. O que eu gostaria de fazer a partir daqui é refazer a ramificação do recurso para a ramificação mestre no controle remoto, mas eu gostaria de fazer isso na minha máquina local. Eu gostaria de poder fazer:

git checkout master
git pull
git checkout feature
git rebase master
git push origin feature

Para manter a ramificação do recurso remoto atualizada com o mestre remoto. No entanto, esse método faz com que o Git se queixe:

To <remote>
 ! [rejected]        feature -> feature (non-fast-forward)
error: failed to push some refs to '<remote>'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes (e.g. 'git pull') before pushing again.  See the
'Note about fast-forwards' section of 'git push --help' for details.

git pullfaz o truque, mas causa uma consolidação de mesclagem que eu gostaria de evitar. Estou preocupado que a mensagem afirme feature -> featuremais do que feature -> origin/featureisso, mas isso pode ser apenas uma coisa de apresentação.

Estou perdendo alguma coisa, ou estou fazendo isso de maneira completamente errada? Não é essencial evitar fazer a rebase no servidor remoto, mas torna muito mais difícil corrigir conflitos de mesclagem da rebase.

Tudo se resume a saber se o recurso é usado por uma pessoa ou se outros estão trabalhando com ele.

Você pode forçar o push após o rebase se for apenas você:

git push origin feature -f

No entanto, se outras pessoas estiverem trabalhando nisso, você deve mesclar e não se recuperar do mestre.

git merge master
git push origin feature

Isso garantirá que você tenha um histórico comum com as pessoas com quem está colaborando.

Em um nível diferente, você não deve fazer fusões inversas. O que você está fazendo é poluir o histórico de sua ramificação de recurso com outras confirmações que não pertencem à característica, dificultando o trabalho subseqüente com essa ramificação - reformulando ou não.

Este é o meu artigo sobre o assunto chamado ramificação por recurso .

Espero que isto ajude.

É bom que você tenha abordado esse assunto.

Essa é uma coisa / conceito importante no git que muitos usuários do git se beneficiariam com o conhecimento. O git rebase é uma ferramenta muito poderosa e permite que você esmague as confirmações em conjunto, remova as confirmações etc. Mas, como qualquer ferramenta poderosa, você basicamente precisa saber o que está fazendo ou algo pode dar realmente errado.

Quando você estiver trabalhando localmente e brincando com suas filiais locais, poderá fazer o que quiser, desde que não tenha enviado as alterações ao repositório central. Isso significa que você pode reescrever sua própria história, mas não outras. Brincando apenas com o material local, nada terá impacto em outros repositórios.

É por isso que é importante lembrar que, depois de enviar confirmações, você não deve recuperá-las posteriormente. A razão pela qual isso é importante é que outras pessoas podem extrair seus commits e basear o trabalho deles em suas contribuições para a base de código, e se você decidir posteriormente mover esse conteúdo de um lugar para outro (refazê-lo) e empurrá-los alterações, outras pessoas terão problemas e precisam refazer o código. Agora imagine que você tenha 1000 desenvolvedores :) Isso causa muitos retrabalhos desnecessários.

Como você se reestruturou featureem cima do novo master, seu local featurenão é mais um avanço rápido origin/feature. Então, acho que é perfeitamente bom substituir a verificação de avanço rápido fazendo isso git push origin +feature. Você também pode especificar isso em sua configuração

git config remote.origin.push +refs/heads/feature:refs/heads/feature

Se outras pessoas trabalharem em cima disso origin/feature, elas serão perturbadas por esta atualização forçada. Você pode evitar isso mesclando o novo masterno em featurevez de rebasear. O resultado será realmente um avanço rápido.

Você pode desativar a verificação (se tiver certeza de que sabe o que está fazendo) usando a --forceopção para git push.