git-rerere - Online na nuvem

PROGRAMA:

NOME

git-rerere - Reutilizar resolução gravada de mesclagens conflitantes

SINOPSE

git reler [remover filtragem|esquecer |diff|remanescente|estado|gc]

DESCRIÇÃO

Em um fluxo de trabalho que emprega ramos de tópicos de duração relativamente longa, o desenvolvedor às vezes
precisa resolver os mesmos conflitos continuamente até que as ramificações do tópico sejam concluídas
(seja mesclado com o branch "release" ou enviado e aceito pelo upstream).

Este comando auxilia o desenvolvedor neste processo, gravando automerge em conflito
resultados e resultados correspondentes de resolução manual na mesclagem manual inicial e aplicação
resoluções de mão previamente gravadas para seus resultados de emergência automática correspondentes.

Note
Você precisa definir a variável de configuração rerere.enabled para habilitar este
comando.

COMANDOS

Normalmente, git reler é executado sem argumentos ou intervenção do usuário. No entanto, tem
vários comandos que permitem que ele interaja com seu estado de trabalho.

remover filtragem
Redefina os metadados usados ​​por rerere se uma resolução de mesclagem for abortada. Chamando git
am [--skip | --abort] or git rebase [--skip | --abort] irá invocar isto automaticamente
comando.

esquecer
Redefina as resoluções de conflito que foram gravadas novamente para o conflito atual em
.

diff
Exibe diferenças para o estado atual da resolução. É útil para rastrear o que
mudou enquanto o usuário está resolvendo conflitos. Argumentos adicionais são passados
diretamente para o sistema diff comando instalado no PATH.

estado
Caminhos de impressão com conflitos cuja resolução de mesclagem novamente será gravada.

remanescente
Imprima caminhos com conflitos que não foram resolvidos automaticamente por meio de um novo relato. Isso inclui
caminhos cujas resoluções não podem ser rastreadas novamente, como submódulos conflitantes.

gc
Remova registros de mesclagens conflitantes que ocorreram há muito tempo. Por padrão,
conflitos não resolvidos com mais de 15 dias e conflitos resolvidos com mais de 60 dias são
podado. Esses padrões são controlados por meio do gc.rerereUnresolved e
Variáveis ​​de configuração gc.rerereResolved respectivamente.

DISCUSSÃO

Quando seu branch de tópico modifica uma área de sobreposição que seu branch master (ou upstream)
tocado desde que seu ramo de tópico bifurcou a partir dele, você pode querer testá-lo com o mais recente
mestre, mesmo antes de seu branch de tópico estar pronto para ser enviado para o upstream:

o --- * --- o tópico
/
o --- o --- o --- * --- o --- o mestre

Para tal teste, você precisa mesclar mestre e tópico de alguma forma. Uma maneira de fazer isso é puxar
mestre no ramo do tópico:

$ git checkout tópico
$ git mestre de mesclagem

o --- * --- o --- + tópico
//
o --- o --- o --- * --- o --- o mestre

Os commits marcados com * tocam a mesma área no mesmo arquivo; você precisa resolver o
conflitos ao criar o commit marcado com +. Então você pode testar o resultado para fazer
certifique-se de que seu trabalho em andamento ainda funcione com o que está no master mais recente.

Após esse teste de mesclagem, há duas maneiras de continuar seu trabalho no tópico. O mais fácil
é construir sobre o teste de mesclagem commit +, e quando seu trabalho no ramo do tópico é
finalmente pronto, coloque o branch do tópico no master e / ou peça ao upstream para puxar
tu. Naquela época, no entanto, o mestre ou o upstream pode ter sido avançado desde o
test merge +, caso em que o gráfico de confirmação final ficaria assim:

$ git checkout tópico
$ git mestre de mesclagem
$ ... trabalhar nos ramos tópico e mestre
$ git checkout mestre
$ git mesclar tópico

o --- * --- o --- + --- o --- o tópico
/ / \
o --- o --- o --- * --- o --- o --- o --- o --- + mestre

Quando o seu ramo de tópico tem vida longa, no entanto, seu ramo de tópico acabaria tendo muitos
tais commits "Merge from master" nele, o que desordenaria desnecessariamente o desenvolvimento
história. Os leitores da lista de discussão do kernel do Linux podem se lembrar que Linus reclamou sobre
tão frequentes testes de mesclagem quando um mantenedor do subsistema pediu para puxar de um ramo completo
de "mesclagens inúteis".

Como alternativa, para manter o ramo do tópico livre de mesclagens de teste, você pode eliminar o
teste a fusão e continue construindo em cima da dica antes da fusão de teste:

$ git checkout tópico
$ git mestre de mesclagem
$ git reset --hard HEAD ^; # retroceder o teste de mesclagem
$ ... trabalhar nos ramos tópico e mestre
$ git checkout mestre
$ git mesclar tópico

o --- * --- o ------- o --- o tópico
/\
o --- o --- o --- * --- o --- o --- o --- o --- + mestre

Isso deixaria apenas um commit de mesclagem quando seu branch de tópico estiver finalmente pronto e mesclado
no branch master. Esta fusão exigiria que você resolvesse o conflito, introduzido
pelos commits marcados com *. No entanto, este conflito é frequentemente o mesmo conflito que você
resolvido quando você criou a mesclagem de teste, você explodiu. git reler te ajuda a resolver isso
fusão conflitante final usando as informações de sua resolução de mão anterior.

Executando o git reler comando imediatamente após uma emergência automática em conflito registrar o
arquivos de árvore de trabalho em conflito, com os marcadores de conflito usuais <<<<<<<, =======, e
>>>>>>> neles. Mais tarde, depois de resolver os conflitos, execute git reler
novamente registrará o estado resolvido desses arquivos. Suponha que você fez isso quando criou
o teste de mesclagem do master no branch do tópico.

Da próxima vez, depois de ver o mesmo automerge em conflito, executando git reler vai realizar um
mesclagem de três vias entre a automerge em conflito anterior, a resolução manual anterior,
e o atual conflito automático. Se esta mesclagem de três vias for resolvida de forma limpa, o resultado
é gravado em seu arquivo de árvore de trabalho, portanto, você não precisa resolvê-lo manualmente. Observação
que git reler deixa o arquivo de índice sozinho, então você ainda precisa fazer a sanidade final
verifica com git diff (ou git diff -c) e git adicionar quando você estiver satisfeito.

Por conveniência, git fundir invoca automaticamente git reler ao sair com um
falha automática e git reler registra a resolução da mão quando é um novo conflito, ou
reutiliza a resolução da mão anterior quando não é. git commit também invoca git reler quando
comprometendo um resultado de mesclagem. O que isso significa é que você não precisa fazer nada de especial
você mesmo (além de habilitar a variável de configuração rerere.enabled).

Em nosso exemplo, quando você faz o teste de mesclagem, a resolução manual é gravada e
ser reutilizado quando você fizer a mesclagem real mais tarde com o master atualizado e o branch de tópico, como
contanto que a resolução gravada ainda seja aplicável.

A informação git reler registros também são usados ​​ao executar git rebase. Depois de soprar
afastar o teste de mesclagem e o desenvolvimento contínuo no ramo do tópico:

o --- * --- o ------- o --- o tópico
/
o --- o --- o --- * --- o --- o --- o --- o mestre

$ git rebase tópico mestre

o --- * --- o ------- o --- o tópico
/
o --- o --- o --- * --- o --- o --- o --- o mestre

você poderia executar git rebase master topic, para ficar atualizado antes que seu tópico seja
pronto para ser enviado a montante. Isso resultaria no retrocesso para uma mesclagem de três vias, e
entraria em conflito da mesma forma que o teste de mesclagem que você resolveu anteriormente. git reler será executado
by git rebase para ajudá-lo a resolver este conflito.

GIT

Parte da git(1) suíte

Use git-rerere online usando serviços onworks.net