git-rebase - Online na nuvem

PROGRAMA:

NOME

git-rebase - Forward-port local commits para o upstream head atualizado

SINOPSE

git rebase [-i | --interactive] [options] [--exec ] [--para ]
[ [ ]]
git rebase [-i | --interactive] [options] [--exec ] [--para ]
--raiz [ ]
git rebase --continuar | --pular | --abortar | --edit-todo

DESCRIÇÃO

Se é especificado, git rebase irá realizar uma verificação automática do git
antes de fazer qualquer outra coisa. Caso contrário, ele permanece na ramificação atual.

Se não for especificado, o upstream configurado no ramo. .remote e
filial. As opções .merge serão usadas (veja git-config(1) para detalhes) e o
A opção --fork-point é assumida. Se você atualmente não está em nenhum ramo ou se o atual
o branch não tem um upstream configurado, o rebase será abortado.

Todas as mudanças feitas por commits no branch atual, mas que não estão em são salvos
para uma área temporária. Este é o mesmo conjunto de commits que seria mostrado pelo git log
..CABEÇA; ou por git log 'fork_point' .. HEAD, se --fork-point estiver ativo (veja o
descrição no --fork-point abaixo); ou por git log HEAD, se a opção --root for especificada.

O ramo atual é redefinido para , ou se a opção --onto foi fornecida.
Isso tem exatamente o mesmo efeito que git reset --hard (ou ) ORIG_HEAD é
definido para apontar para a ponta do galho antes da reinicialização.

Os commits que foram salvos anteriormente na área temporária são então reaplicados ao
ramo atual, um por um, em ordem. Observe que quaisquer commits no HEAD que apresentem o
mesmas alterações textuais de um commit em HEAD .. são omitidos (ou seja, um patch já
o upstream aceito com uma mensagem de confirmação ou carimbo de data / hora diferente será ignorado).

É possível que uma falha de mesclagem impeça este processo de ser completamente
automático. Você terá que resolver qualquer falha de mesclagem e executar git rebase --continue.
Outra opção é ignorar o commit que causou a falha de mesclagem com git rebase
--pular. Para verificar o original e remover os arquivos de trabalho .git / rebase-apply,
use o comando git rebase --abort.

Suponha que o seguinte histórico exista e o branch atual seja "tópico":

Tópico A --- B --- C
/
D --- E --- F --- G mestre

A partir deste ponto, o resultado de um dos seguintes comandos:

mestre de rebase git
tópico git rebase master

seria:

Tópico A '- B' - C '
/
D --- E --- F --- G mestre

OBSERVAÇÃO: A última forma é apenas uma abreviação do tópico de verificação git seguido por git rebase
mestre. Quando o rebase sair, o tópico permanecerá como o ramo em check-out.

Se o branch upstream já contém uma mudança que você fez (por exemplo, porque você enviou um
patch que foi aplicado no upstream), então esse commit será ignorado. Por exemplo, correr
git rebase master no seguinte histórico (no qual A 'e A apresentam o mesmo conjunto de
alterações, mas têm informações de committer diferentes):

Tópico A --- B --- C
/
D --- E --- A '--- F mestre

vai resultar em:

Tópico B '--- C'
/
D --- E --- A '--- F mestre

Aqui está como você transplantaria um ramo de tópico baseado em um ramo para outro, para fingir
que você bifurcou o branch do tópico do último branch, usando rebase --onto.

Primeiro, vamos supor que o seu tópico é baseado no ramo Próximo. Por exemplo, um recurso desenvolvido em
tópico depende de alguma funcionalidade encontrada em Próximo.

o --- o --- o --- o --- o mestre
\
o --- o --- o --- o --- o próximo
\
o --- o --- o tópico

Nós queremos fazer tópico bifurcada do ramo dominar; por exemplo, porque a funcionalidade em
qual tópico depende foi fundido no mais estável dominar filial. Queremos que nossa árvore
parece com isso:

o --- o --- o --- o --- o mestre
| \
| o '- o' - o 'tópico
\
o --- o --- o --- o --- o próximo

Podemos obter isso usando o seguinte comando:

git rebase --onto master próximo tópico

Outro exemplo da opção --onto é realocar parte de um branch. Se tivermos o seguinte
situação:

H --- I --- J tópico B
/
E --- F --- G tópico A
/
A --- B --- C --- D mestre

então o comando

git rebase --onto tópico mestreA tópicoB

resultaria em:

H '- I' - J 'tópico B
/
| E --- F --- G tópico A
|/
A --- B --- C --- D mestre

Isso é útil quando o tópico B não depende do tópicoA.

Uma série de confirmações também pode ser removida com rebase. Se tivermos a seguinte situação:

E --- F --- G --- H --- I --- J tópico A

então o comando

git rebase --onto tópicoA ~ 5 tópicoA ~ 3 tópicoA

resultaria na remoção dos commits F e G:

E --- H '--- I' --- J 'tópicoA

Isso é útil se F e G tiverem falhas de alguma forma, ou não deveriam fazer parte do tópicoA. Observação
que o argumento para --onto e o parâmetro pode ser qualquer commit-ish válido.

Em caso de conflito, git rebase irá parar no primeiro commit problemático e sair
marcadores de conflito na árvore. Você pode usar git diff para localizar os marcadores (<<<<<<) e fazer
edições para resolver o conflito. Para cada arquivo editado, você precisa informar ao Git que o
conflito foi resolvido, normalmente isso seria feito com

git add

Depois de resolver o conflito manualmente e atualizar o índice com a resolução desejada,
você pode continuar o processo de rebase com

git rebase --continua

Alternativamente, você pode desfazer o git rebase com

git rebase --abort

CONFIGURAÇÃO

rebase.stat
Se deve mostrar um diffstat do que mudou no upstream desde o último rebase. Falso por
padrão.

rebase.autoSquash
Se definido como verdadeiro, habilite --autosquash opção por padrão.

rebase.autoStash
Se definido como verdadeiro, habilite --autostash opção por padrão.

rebase.missingCommitsCheck
Se definido como "warn", imprime avisos sobre commits removidos no modo interativo. Se definido para
"erro", imprime os avisos e interrompe o rebase. Se definido como "ignorar", nenhuma verificação é
feito. "ignore" por padrão.

rebase.instructionFormat
Formato de lista de confirmação personalizada para usar durante um --interativo rebase.

OPÇÕES

--para
Ponto de partida para criar os novos commits. Se a opção --onto não for
especificado, o ponto de partida é . Pode ser qualquer commit válido, e não apenas um
nome da filial existente.

Como um caso especial, você pode usar "A ... B" como um atalho para a base de fusão de A e B se
há exatamente uma base de mesclagem. Você pode omitir no máximo um de A e B, no qual
caso, o padrão é HEAD.


Ramificação upstream para comparação. Pode ser qualquer commit válido, não apenas um existente
nome do ramo. O padrão é o upstream configurado para a ramificação atual.


Ramo de trabalho; o padrão é HEAD.

--Prosseguir
Reinicie o processo de rebase após ter resolvido um conflito de mesclagem.

--abortar
Aborte a operação de rebase e redefina o HEAD para o branch original. Se era
fornecido quando a operação de rebase foi iniciada, o HEAD será redefinido para .
Caso contrário, o HEAD será redefinido para onde estava quando a operação de rebase foi iniciada.

--manter-vazio
Guarde os commits que não alteram nada de seus pais no resultado.

--pular
Reinicie o processo de rebase pulando o patch atual.

--edit-todo
Edite a lista de tarefas durante um rebase interativo.

-m, --mesclar
Use estratégias de mesclagem para rebase. Quando a estratégia de mesclagem recursiva (padrão) é usada,
isso permite que o rebase esteja ciente das renomeações no lado upstream.

Observe que uma fusão de rebase funciona repetindo cada commit do branch de trabalho no topo
do filial. Por causa disso, quando ocorre um conflito de mesclagem, o lado
relatado como nosso é a série rebaseada até agora, começando com , e deles is
o ramo de trabalho. Em outras palavras, os lados são trocados.

-s , --strategy =
Use a estratégia de mesclagem fornecida. Se não houver opção -s git mesclar-recursivo é usado
em vez de. Isso implica --merge.

Porque git rebase repete cada commit do branch de trabalho no topo do
ramo usando a estratégia dada, usando o nosso estratégia simplesmente descarta
todos os patches do , o que faz pouco sentido.

-X , - opção-estratégia =
Passe o até a estratégia de fusão. Isso implica --merge e, se
nenhuma estratégia foi especificada, -s recursiva. Observe a reversão de nosso e deles as
anotado acima para a opção -m.

-S [ ], - sinal gpg [= ]
Confirmações de sinal GPG. O argumento keyid é opcional e o padrão é o committer
identidade; se especificado, ele deve ser preso à opção sem um espaço.

-q, --quieto
Fique quieto. Implica --no-stat.

-v, --verboso
Seja prolixo. Implica --stat.

--Estado
Mostra um diffstat do que mudou no upstream desde o último rebase. O diffstat também é
controlado pela opção de configuração rebase.stat.

-n, --no-stat
Não mostre um diffstat como parte do processo de rebase.

--no-verify
Esta opção ignora o gancho pré-rebase. Veja também gitooks(5).

--verificar
Permite que o gancho pré-rebase seja executado, que é o padrão. Esta opção pode ser usada para
substituir --no-verify. Veja também gitooks(5).

-C
Certifique-se de pelo menos as linhas do contexto circundante correspondem antes e depois de cada mudança.
Quando existem menos linhas do contexto circundante, todas elas devem corresponder. Por padrão não
o contexto é sempre ignorado.

-f, --force-rebase
Força um rebase mesmo se o branch atual estiver atualizado e o comando sem
--force retornaria sem fazer nada.

Você pode achar isto (ou --no-ff com um rebase interativo) útil após reverter um
fusão de ramificação de tópico, pois esta opção recria a ramificação de tópico com novos commits para que
pode ser reativado com sucesso sem a necessidade de "reverter a reversão" (ver o
reverter uma mesclagem com defeito How-To[1] para detalhes).

--ponto de bifurcação, --sem ponto de bifurcação
Use reflog para encontrar um ancestral comum melhor entre e quando
calcular quais commits foram introduzidos por .

Quando --fork-point está ativo, ponto_da_bifurcação será usado em vez de para
calcular o conjunto de commits para rebase, onde ponto_da_bifurcação é o resultado do git
merge-base --fork-point comando (ver git-merge-base(1)). Se
ponto_da_bifurcação acaba ficando vazio, o será usado como um substituto.

Se algum ou --root é fornecido na linha de comando, então o padrão é
--no-fork-point, caso contrário, o padrão é --fork-point.

--ignore-whitespace, --whitespace =
Estas bandeiras são passadas para o git Aplique programa (ver git-apply(1)) que aplica o
correção. Incompatível com a opção --interactive.

--committer-date-is-author-date, --ignore-date
Essas bandeiras são passadas para git am para alterar facilmente as datas dos commits realocados
(Vejo git-sou(1)). Incompatível com a opção --interactive.

-i, --interativo
Faça uma lista dos commits que estão prestes a serem rebaseeados. Deixe o usuário editar essa lista
antes de rebase. Este modo também pode ser usado para dividir commits (veja DIVIDINDO COMITES
abaixo).

O formato da lista de confirmação pode ser alterado definindo a opção de configuração
rebase.instructionFormat. Um formato de instrução personalizado terá automaticamente o
long commit hash prefixado ao formato.

-p, --preserve-merge
Recrie os commits de mesclagem em vez de nivelar o histórico reproduzindo os commits em uma mesclagem
commit introduz. Combine resoluções de conflito ou emendas manuais para mesclar commits
não são preservados.

Isso usa o - maquinário interativo internamente, mas combinando-o com o
--opção interativa explicitamente geralmente não é uma boa ideia, a menos que você saiba o que
estão fazendo (veja os BUGS abaixo).

-x , --exec
Anexar "exec "após cada linha, criando um commit no histórico final. vai
ser interpretado como um ou mais comandos do shell.

Esta opção só pode ser usada com a opção --interactive (veja MODO INTERATIVO
abaixo).

Você pode executar vários comandos usando uma instância de --exec com vários
comandos:

git rebase -i --exec "cmd1 && cmd2 && ..."

ou dando mais de um --exec:

git rebase -i --exec "cmd1" --exec "cmd2" --exec ...

Se --autosquash for usado, as linhas "exec" não serão anexadas para o intermediário
confirma, e só aparecerá no final de cada série de squash / fixup.

--raiz
Rebase todos os commits acessíveis de , em vez de limitá-los com um
. Isso permite que você rebase o (s) commit (s) root em um branch. Quando usado com
--onto, ele irá pular as mudanças já contidas em (ao invés de )
enquanto que sem --onto ele operará em todas as mudanças. Quando usado junto com ambos
--onto e --preserve-merges, todos os root commits serão reescritos para terem Como
pai em vez disso.

--autosquash, --no-autosquash
Quando a mensagem de log do commit começa com "squash! ..." (ou "fixup! ..."), e há
um commit cujo título começa com o mesmo ..., modifica automaticamente a lista de tarefas de
rebase -i para que o commit marcado para esmagamento venha logo após o commit para ser
modificado e muda a ação do commit movido de pick para squash (ou fixup).
Ignora o subsequente "conserto!" Ou "squash!" Após o primeiro, caso você tenha se referido a um
correção / squash anterior com git commit --fixup / - squash.

Esta opção só é válida quando o --interativo opção é usada.

Se o --autosquash opção está habilitada por padrão usando a variável de configuração
rebase.autoSquash, esta opção pode ser usada para substituir e desabilitar esta configuração.

--autostash, --no-autostash
Crie automaticamente um estoque temporário antes do início da operação e aplique-o depois
a operação termina. Isso significa que você pode executar o rebase em uma árvore de trabalho suja. Contudo,
use com cuidado: o aplicativo de stash final após um rebase bem-sucedido pode resultar em
conflitos não triviais.

--não-ff
Com --interactive, selecione todos os commits com base no rebase em vez de avançar rapidamente
os inalterados. Isso garante que todo o histórico do ramo com base no rebase seja
composto de novos commits.

Sem --interactive, este é um sinônimo para --force-rebase.

Você pode achar isso útil depois de reverter uma mesclagem de ramificação de tópico, pois esta opção
recria o branch do tópico com novos commits para que possa ser reativado com sucesso
sem precisar "reverter a reversão" (veja o reverter uma mesclagem com defeito How-To[1] para
detalhes).

MERGE ESTRATÉGIAS

O mecanismo de mesclagem (comandos git merge e git pull) permite que o backend fundir estratégias
a ser escolhido com a opção -s. Algumas estratégias também podem ter suas próprias opções, que podem ser
passou dando -X argumentos para git merge e / ou git pull.

resolver
Isso só pode resolver duas cabeças (ou seja, a ramificação atual e outra ramificação que você puxou
de) usando um algoritmo de mesclagem de 3 vias. Ele tenta detectar cuidadosamente a fusão cruzada
ambigüidades e é considerado geralmente seguro e rápido.

recursiva
Isso pode resolver apenas duas cabeças usando um algoritmo de mesclagem de 3 vias. Quando há mais de
um ancestral comum que pode ser usado para mesclagem de 3 vias, ele cria uma árvore mesclada do
ancestrais comuns e usa isso como a árvore de referência para a fusão de 3 vias. Este tem
foi relatado como resultando em menos conflitos de mesclagem, sem causar erros de mesclagem por testes
feito em commits de mesclagem reais retirados do histórico de desenvolvimento do kernel do Linux 2.6.
Além disso, pode detectar e tratar mesclagens envolvendo renomeações. Este é o padrão
estratégia de fusão ao puxar ou fundir um ramo.

A recursiva estratégia pode ter as seguintes opções:

nosso
Esta opção força os blocos conflitantes a serem resolvidos automaticamente de forma limpa, favorecendo A Nossa
versão. Mudanças da outra árvore que não entram em conflito com o nosso lado são
refletido no resultado da fusão. Para um arquivo binário, todo o conteúdo é obtido
do nosso lado.

Isso não deve ser confundido com o nosso estratégia de fusão, que nem parece
no que a outra árvore contém. Ela descarta tudo que a outra árvore fez,
declarando A Nossa a história contém tudo o que aconteceu nela.

deles
Este é o oposto de nosso.

paciência
Com esta opção, mesclar-recursivo gasta um pouco mais de tempo para evitar erros
que às vezes ocorrem devido a linhas de correspondência sem importância (por exemplo, colchetes de linhas distintas
funções). Use isto quando as ramificações a serem mescladas divergiram radicalmente. Veja também
git-diff(1) - paciência.

algoritmo diff = [paciência | mínimo | histograma | myers]
Diz mesclar-recursivo para usar um algoritmo de diff diferente, o que pode ajudar a evitar
mismerges que ocorrem devido a linhas de correspondência sem importância (como colchetes de
funções distintas). Veja também git-diff(1) - algoritmo-dif.

ignore-space-change, ignore-all-space, ignore-space-at-eol
Trata as linhas com o tipo indicado de mudança de espaço em branco como inalteradas para o
uma fusão de três vias. Mudanças de espaço em branco misturadas com outras mudanças em uma linha
não são ignorados. Veja também git-diff(1) -b, -w, e --ignore-space-at-eol.

· Se deles versão apenas introduz mudanças de espaço em branco em uma linha, A Nossa versão é
usado;

· Se A Nossa versão introduz alterações de espaço em branco, mas deles a versão inclui um
mudança substancial, deles versão é usada;

· Caso contrário, a fusão continua da maneira usual.

renormalizar
Isso executa um check-out e check-in virtuais de todas as três fases de um arquivo quando
resolver uma fusão de três vias. Esta opção deve ser usada ao mesclar ramos
com diferentes filtros de limpeza ou regras de normalização de fim de linha. Veja "Mesclando
branches com diferentes atributos de check-in / check-out "em gitatributes(5) para
Detalhes.

não renormalizar
Desativa a opção renormalize. Isso substitui o merge.renormalize
configuração variável.

rename-threshold =
Controla o limite de similaridade usado para detecção de renomeação. Veja também git-diff(1)
-Senhor.

subárvore [= ]
Esta opção é uma forma mais avançada de subárvore estratégia, onde a estratégia faz
um palpite sobre como duas árvores devem ser deslocadas para combinar uma com a outra durante a fusão.
Em vez disso, o caminho especificado é prefixado (ou retirado do início) para tornar
a forma de duas árvores para combinar.

polvo
Isso resolve os casos com mais de duas cabeças, mas se recusa a fazer uma mesclagem complexa que
precisa de resolução manual. Destina-se principalmente a ser usado para agrupar ramo de tópico
cabeças juntas. Esta é a estratégia de mesclagem padrão ao extrair ou mesclar mais de
um ramo.

nosso
Isso resolve qualquer número de cabeças, mas a árvore resultante da fusão é sempre aquela
do chefe da ramificação atual, ignorando efetivamente todas as alterações de todas as outras ramificações.
Ele deve ser usado para substituir o antigo histórico de desenvolvimento de ramificações laterais. Observação
que isso é diferente da opção -Xours para o recursiva estratégia de fusão.

subárvore
Esta é uma estratégia recursiva modificada. Ao fundir as árvores A e B, se B corresponder a
uma subárvore de A, B é primeiro ajustada para coincidir com a estrutura da árvore de A, em vez de
lendo as árvores no mesmo nível. Este ajuste também é feito para o comum
árvore ancestral.

Com as estratégias que usam mesclagem de 3 vias (incluindo o padrão, recursiva), se uma mudança
é feita em ambas as ramificações, mas posteriormente revertida em uma das ramificações, essa mudança será
presente no resultado da fusão; algumas pessoas acham esse comportamento confuso. Ocorre porque
apenas as cabeças e a base de mesclagem são consideradas ao realizar uma mesclagem, não o
commits individuais. O algoritmo de mesclagem, portanto, considera a alteração revertida como não
mude em tudo e substitua a versão alterada em seu lugar.

NOTAS

Você deve compreender as implicações de usar git rebase em um repositório que você compartilha.
Veja também RECOVERING FROM UPSTREAM REBASE abaixo.

Quando o comando git-rebase é executado, ele primeiro executa um gancho "pré-rebase" se houver
existe. Você pode usar este gancho para fazer verificações de integridade e rejeitar o rebase se não for
apropriado. Consulte o script de gancho pré-rebase do modelo para obter um exemplo.

Após o término, será o ramo atual.

INTERATIVO MODA

Rebasing interativamente significa que você tem a chance de editar os commits que são rebaseados.
Você pode reordenar os commits, e você pode removê-los (eliminando mal ou de outra forma
patches indesejados).

O modo interativo é destinado a este tipo de fluxo de trabalho:

1. tenho uma ideia maravilhosa

2. hackear o código

3. preparar uma série para apresentação

4. submeter

onde o ponto 2. consiste em várias instâncias de

a) uso regular

1. terminar algo digno de um commit

2. comprometer

b) arranjo independente

1. perceber que algo não funciona

2. consertar isso

3. cometê-lo

Às vezes, a coisa corrigida em b.2. não pode ser alterado para o commit não muito perfeito
correções, porque esse commit está profundamente enterrado em uma série de patch. Isso é exatamente o que
o rebase interativo é para: use-o depois de muitos "a" se "b" s, reorganizando e
editando commits e comprimindo vários commits em um.

Comece com o último commit que você deseja manter no estado em que se encontra:

git rebase -i

Um editor será iniciado com todos os commits do seu branch atual (ignorando o merge
commits), que vêm após o commit fornecido. Você pode reordenar os commits nesta lista para
o conteúdo do seu coração, e você pode removê-los. A lista é mais ou menos assim:

pick deadbee O oneline deste commit
pick fa1afe1 O oneline do próximo commit
...

As descrições online são puramente para seu prazer; git rebase não vou olhar para eles
mas nos nomes de commit ("deadbee" e "fa1afe1" neste exemplo), então não exclua ou
edite os nomes.

Substituindo o comando "pick" pelo comando "edit", você pode saber git rebase parar
depois de aplicar esse commit, para que você possa editar os arquivos e / ou a mensagem de commit,
corrija o commit e continue rebasing.

Se você deseja apenas editar a mensagem de confirmação para uma confirmação, substitua o comando "pick" por
o comando "reformular".

Para descartar um commit, substitua o comando "pick" por "drop", ou apenas exclua o correspondente
linha.

Se você quiser dobrar dois ou mais commits em um, substitua o comando "pick" pelo
segundo commits e subseqüentes com "squash" ou "fixup". Se os commits tivessem diferentes
autores, o commit dobrado será atribuído ao autor do primeiro commit. o
A mensagem de commit sugerida para o commit dobrado é a concatenação das mensagens de commit
do primeiro commit e daqueles com o comando "squash", mas omite as mensagens de commit
de commits com o comando "fixup".

git rebase irá parar quando "pick" for substituído por "edit" ou quando um comando falhar devido
para mesclar erros. Quando terminar de editar e / ou resolver conflitos, você pode continuar
com git rebase --continue.

Por exemplo, se você quiser reordenar os últimos 5 commits, de forma que o que era HEAD ~ 4 se torne
o novo CABEÇA. Para conseguir isso, você chamaria git rebase como isso:

$ git rebase -i HEAD ~ 5

E mova o primeiro patch para o final da lista.

Você pode querer preservar as mesclagens, se tiver um histórico como este:

X
\
A --- M --- B
/
--- o --- O --- P --- Q

Suponha que você queira realocar o branch lateral começando em "A" para "Q". Certifique-se de que o
HEAD atual é "B", e ligue

$ git rebase -i -p --onto QO

Reordenar e editar commits geralmente cria etapas intermediárias não testadas. Você pode querer
para verificar se a edição do seu histórico não quebrou nada executando um teste, ou pelo menos
recompilar em pontos intermediários da história usando o comando "exec" (atalho "x").
Você pode fazer isso criando uma lista de tarefas como esta:

pick deadbee Implementar recurso XXX
fixup f1a5c00 Correção para o recurso XXX
executivo faz
pick c0ffeee O oneline do próximo commit
editar deadbab O oneline do commit após
exec cd subdir; fazer teste
...

O rebase interativo irá parar quando um comando falhar (ou seja, sai com status diferente de 0) para
dar-lhe a oportunidade de resolver o problema. Você pode continuar com git rebase --continue.

O comando "exec" lança o comando em um shell (aquele especificado em $ SHELL, ou o
shell padrão se $ SHELL não estiver definido), para que você possa usar os recursos do shell (como "cd", ">", ";"
...). O comando é executado a partir da raiz da árvore de trabalho.

$ git rebase -i --exec "fazer teste"

Este comando permite que você verifique se os commits intermediários são compiláveis. A lista de tarefas
fica assim:

escolha 5928aea um
exec fazer teste
escolha 04d0fda dois
exec fazer teste
escolha ba46169 três
exec fazer teste
escolha f4593f9 quatro
exec fazer teste

DIVISÃO COMPROMETE

No modo interativo, você pode marcar commits com a ação "editar". No entanto, isso não
necessariamente significa que git rebase espera que o resultado desta edição seja exatamente um commit.
Na verdade, você pode desfazer o commit ou pode adicionar outros commits. Isso pode ser usado para dividir um
comprometa-se em dois:

· Inicie um rebase interativo com git rebase -i ^, onde é o commit
você deseja dividir. Na verdade, qualquer intervalo de commit servirá, contanto que contenha aquele
comprometer-se.

· Marque o commit que deseja dividir com a ação "editar".

· Quando se trata de editar esse commit, execute git reset HEAD ^. O efeito é que o
HEAD é rebobinado em um, e o índice segue o exemplo. No entanto, a árvore de trabalho permanece
o mesmo.

· Agora adicione as mudanças ao índice que você deseja ter no primeiro commit. Você pode
use git add (possivelmente interativamente) ou git gui (ou ambos) para fazer isso.

· Confirme o índice agora atual com qualquer mensagem de confirmação apropriada agora.

· Repita as duas últimas etapas até que sua árvore de trabalho esteja limpa.

· Continue o rebase com git rebase --continue.

Se você não tem certeza absoluta de que as revisões intermediárias são consistentes (elas
compilar, passar no teste, etc.) que você deve usar git esconder para esconder o
alterações ainda não confirmadas após cada confirmação, teste e alteração da confirmação se as correções forem
necessário.

RECUPERANDO A PARTIR DE MONTANTE REBASE

Rebasear (ou qualquer outra forma de reescrever) um branch no qual outros basearam o trabalho é uma péssima
ideia: qualquer pessoa a jusante dele é forçada a consertar manualmente seu histórico. Esta seção
explica como fazer a correção do ponto de vista do downstream. A verdadeira correção, no entanto,
seria evitar rebasing o upstream em primeiro lugar.

Para ilustrar, suponha que você esteja em uma situação em que alguém desenvolve um subsistema galho,
e você está trabalhando em um tópico que depende disso subsistema. Você pode acabar com
uma história como a seguinte:

o --- o --- o --- o --- o --- o --- o --- o --- o mestre
\
o --- o --- o --- o --- o subsistema
\
*---*---* tema

If subsistema é rebaseado contra dominar, acontece o seguinte:

o --- o --- o --- o --- o --- o --- o --- o mestre
\\
o --- o --- o --- o --- o '- o' - o '- o' - o 'subsistema
\
*---*---* tema

Se você continuar o desenvolvimento como de costume e, eventualmente, mesclar tópico para subsistema,
confirma de subsistema permanecerá duplicado para sempre:

o --- o --- o --- o --- o --- o --- o --- o mestre
\\
o --- o --- o --- o --- o '- o' - o '- o' - o '- subsistema M
\ /
*---*---*-..........-*--* tema

Essas duplicatas são geralmente desaprovadas porque confundem a história, tornando-a
mais difícil de seguir. Para limpar as coisas, você precisa transplantar os commits em tópico ao
novo subsistema dica, ou seja, rebase tópico. Isso se torna um efeito cascata: qualquer pessoa a jusante
da tópico é forçado a rebase também, e assim por diante!

Existem dois tipos de correções, discutidas nas seguintes subseções:

Caso fácil: as mudanças são literalmente as mesmas.
Isso acontece se o subsistema O rebase era um rebase simples e não tinha conflitos.

Caso difícil: as mudanças não são as mesmas.
Isso acontece se o subsistema rebase teve conflitos, ou usado --interativo para omitir,
edit, squash, ou fixup commits; ou se o upstream usou commit --amend, reset,
ou ramo de filtro.

A fácil casas
Só funciona se as alterações (IDs de patch com base no conteúdo do diff) em subsistema e guarante que os mesmos estão
literalmente o mesmo antes e depois do rebase subsistema fez.

Nesse caso, a correção é fácil porque git rebase sabe pular mudanças que já são
presente no novo upstream. Então, se você disser (assumindo que você está no tópico)

subsistema $ git rebase

você vai acabar com a história fixa

o --- o --- o --- o --- o --- o --- o --- o mestre
\
o '- o' - o '- o' - o 'subsistema
\
*---*---* tema

A difícil casas
As coisas ficam mais complicadas se o subsistema as mudanças não correspondem exatamente às
antes do rebase.

Note
Embora uma "recuperação de caso fácil" às vezes pareça ser bem-sucedida, mesmo no difícil
caso, pode ter consequências indesejadas. Por exemplo, um commit que foi removido via
git rebase --interactive será ressuscitado!

A ideia é contar manualmente git rebase "onde o velho subsistema terminou e seu tópico
começou ", isto é, qual era a antiga base de fusão entre eles. Você terá que encontrar uma maneira de
Nomeie o último commit do antigo subsistema, Por exemplo:

· Com o subsistema reflog: depois git buscar, a velha dica de subsistema está em
subsistema @ {1}. As buscas subsequentes irão aumentar o número. (Ver git-reflog(1).)

· Relativo à ponta de tópico: sabendo que seu tópico tem três commits, a velha dica
of subsistema deve ser o tópico ~ 3.

Você pode então transplantar o antigo subsistema .. tópico para a nova dica dizendo (para o reflog
caso, e supondo que você esteja tópico já):

$ git rebase --onto subsystem subsystem @ {1}

O efeito cascata de uma recuperação de "caso difícil" é especialmente ruim: todos a jusante de
tópico agora terá que realizar uma recuperação de "caso difícil" também!

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