Quando estou trabalhando em uma ramificação de recursos, tenho a tendência de limpar as confirmações na ramificação usando uma rebase interativa antes que meu trabalho seja revisado e integrado na ramificação principal.

Durante o desenvolvimento do recurso, desejo enviar meu trabalho intermediário para o repositório remoto como uma medida de backup. Ou seja, quando meu disco rígido falha, não quero que todo o meu ramo de recursos seja perdido.

No entanto, isso leva ao fato de que muitas vezes tenho que fazer um git push --forceno repositório remoto após uma nova refazer, uma ação que geralmente é desaprovada. Ou como a página vinculada do github diz:

Como alterar seu histórico de consolidação pode dificultar as coisas para todos os outros que usam o repositório, é considerado uma prática recomendada refazer a consolidação quando você já enviou por push a um repositório.

Existe uma política (geralmente aceita) que resolva esse conflito?

Por que essa não é uma duplicata de O git "Regra de Ouro do Rebasamento" é tão essencial?

Minha pergunta aqui pede uma política para resolver o conflito entre querer fazer backup do seu trabalho no repositório remoto e refazer o seu trabalho , enquanto a outra pergunta tenta negar a existência de um conflito e pergunta por que algumas pessoas pensam que o conflito existe, e, portanto, pergunta por que "é essencial" não pressionar rebotes de força?

A principal pergunta a se fazer:

• Você mantém sua ramificação remota após a fusão novamente no mestre?

Se você excluir sua ramificação de recurso remoto após mesclar no master, você já estará perdendo o histórico. Supondo que você esmague / refaça o ramo antes de fazer sua mesclagem / RP, você perderá esse histórico. Todo o seu esforço de força está fazendo neste caso, permitindo que você use o github como um backup.

A situação em que você deseja manter o histórico e não forçar o envio é se o seu ramo remoto persistir após a mesclagem e não existir apenas por um período temporário.

Suponho que você esteja perguntando se eu manteria o ramo não-baseado. Não, AFAIC. Ainda assim, forçar o push pode resultar em perda de confirmações de outros usuários que enviaram para o mesmo ramo

Parece que você tem várias pessoas empurrando para esse ramo simultaneamente. Isto significa que você fazer se preocupam com a história no ramo.

O que você poderia fazer no seu trabalho intermediário é criar uma bifurcação desse ramo. Você pode fazer isso e, em seguida, refazer todas as suas confirmações em uma única confirmação antes da mesclagem; portanto, quando você as mescla em seu ramo de recursos, você tem apenas 1 confirmação (com o histórico recuperado de todo o ramo).

Estou listando aqui algumas possibilidades que me passam pela cabeça.

Sempre rebase em uma nova ramificação

Ao ter uma ramificação bagunçada some-feature, redefina-a em uma nova ramificação. Por exemplo

$ git checkout -b some-feature-rebase
$ git rebase -i master # etc..

Em seguida, some-feature-rebasereviram e integraram.

Problema: Uma grande desvantagem aqui é que, estritamente falando, você precisa de uma nova ramificação para cada rebase. (Você pode ter várias refazer as análises se fizer alterações após uma revisão de código, por exemplo)

Usar git push --force-with-lease

Acabei de aprender sobre a git push --force-with-leasealternativagit push --force , que

se recusa a atualizar uma ramificação, a menos que seja o estado que esperamos; ou seja, ninguém atualizou o ramo a montante.

Problema : isso parece melhorar diretamente a situação em que usamos apenas --force, mas ainda tem algumas ressalvas, principalmente quando eu faço um em git fetchvez de um git pull, que atualiza nossas filiais locais de upstream, tentando --force-with-leasepensar que nenhuma alteração imersa foi feita no controle remoto ramo.