git-rebase - Reaplique os commits em cima do topo de outra base

If <branch> is specified, git rebase will perform an automatic git switch <branch> before doing anything else. Otherwise it remains on the current branch.

If <upstream> is not specified, the upstream configured in branch.<name>.remote and branch.<name>.merge options will be used (see git-config[1] for details) and the --fork-point option is assumed. If you are currently not on any branch or if the current branch does not have a configured upstream, the rebase will abort.

All changes made by commits in the current branch but that are not in <upstream> are saved to a temporary area. This is the same set of commits that would be shown by git log <upstream>..HEAD; or by git log 'fork_point'..HEAD, if --fork-point is active (see the description on --fork-point below); or by git log HEAD, if the --root option is specified.

The current branch is reset to <upstream> or <newbase> if the --onto option was supplied. This has the exact same effect as git reset --hard <upstream> (or <newbase>). ORIG_HEAD is set to point at the tip of the branch before the reset.

Os commits que foram salvos anteriormente na área temporária são reaplicadas no ramo atual, uma por uma e em ordem. Observe que quaisquer commits no HEAD que introduzam as mesmas alterações textuais que um commit no HEAD..<upstream> são omitidas (ou seja, um patch já aceito na inicial com uma mensagem de commit ou carimbo de data e hora diferente, serão ignorados).

It is possible that a merge failure will prevent this process from being completely automatic. You will have to resolve any such merge failure and run git rebase --continue. Another option is to bypass the commit that caused the merge failure with git rebase --skip. To check out the original <branch> and remove the .git/rebase-apply working files, use the command git rebase --abort instead.

Suponha que o seguinte histórico exista e que o ramo atual seja "topic":

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

seria:

NOTE: The latter form is just a short-hand of git checkout topic followed by git rebase master. When rebase exits topic will remain the checked-out branch.

If the upstream branch already contains a change you have made (e.g., because you mailed a patch which was applied upstream), then that commit will be skipped and warnings will be issued (if the merge backend is used). For example, running git rebase master on the following history (in which A' and A introduce the same set of changes, but have different committer information):

vai resultar em:

Aqui está como você transplantaria um ramo do tópico com base num ramo para outro, para fingir que você bifurcou o ramo do tópico deste último ramo, utilizando rebase --onto.

First let’s assume your topic is based on branch next. For example, a feature developed in topic depends on some functionality which is found in next.

Queremos criar um tópico bifurcado no ramo master; porque a funcionalidade da qual o tópico depende foi mesclado na ramificação master mais estável. Queremos que a nossa árvore fique assim:

Podemos conseguir isso utilizando o seguinte comando:

Another example of --onto option is to rebase part of a branch. If we have the following situation:

então o comando

resultaria em:

É útil quando o topicB não depender do topicA.

A range of commits could also be removed with rebase. If we have the following situation:

então o comando

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

This is useful if F and G were flawed in some way, or should not be part of topicA. Note that the argument to --onto and the <upstream> parameter can be any valid commit-ish.

In case of conflict, git rebase will stop at the first problematic commit and leave conflict markers in the tree. You can use git diff to locate the markers (<<<<<<) and make edits to resolve the conflict. For each file you edit, you need to tell Git that the conflict has been resolved, typically this would be done with

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

Como alternativa, você pode desfazer o git rebase com

As opções nesta seção, não podem ser usadas com nenhuma outra opção, inclusive entre si:

As seguintes opções:

são incompatíveis com as seguintes opções:

Além disso, os seguintes pares de opções são incompatíveis:

git rebase has two primary backends: apply and merge. (The apply backend used to be known as the am backend, but the name led to confusion as it looks like a verb instead of a noun. Also, the merge backend used to be known as the interactive backend, but it is now used for non-interactive cases as well. Both were renamed based on lower-level functionality that underpinned each.) There are some subtle differences in how these two backends behave:

O mecanismo da mesclagem (comandos git merge e git pull) permite que as estruturas das estratégias de mesclagem sejam escolhidas com a opção -s. Algumas estratégias também podem ter suas próprias opções, que podem ser passadas usando -X<opção> como argumentos para o comando git merge e/ou git pull.

Com as estratégias que usma a mesclagem de 3 vias (incluindo a predefinição, ort), caso uma alteração seja feita em ambas as ramificações, porém depois revertida em uma das ramificações, essa alteração estará presente no resultado mesclado; algumas pessoas acham este comportamento confuso. Isso ocorre porque apenas os cabeçalhos e a base da mesclagem são consideradas ao fazer uma mesclagem, e não os commits individuais. Portanto, o algoritmo da mesclagem considera a alteração revertida como nenhuma alteração e substitui a versão alterada.

You should understand the implications of using git rebase on a repository that you share. See also RECOVERING FROM UPSTREAM REBASE below.

When the rebase is run, it will first execute a pre-rebase hook if one exists. You can use this hook to do sanity checks and reject the rebase if it isn’t appropriate. Please see the template pre-rebase hook script for an example.

Após a conclusão, o <ramo> será o ramo atual.

Rebasing interactively means that you have a chance to edit the commits which are rebased. You can reorder the commits, and you can remove them (weeding out bad or otherwise unwanted patches).

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

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

a) uso regular

b) correção independente

Sometimes the thing fixed in b.2. cannot be amended to the not-quite perfect commit it fixes, because that commit is buried deeply in a patch series. That is exactly what interactive rebase is for: use it after plenty of "a"s and "b"s, by rearranging and editing commits, and squashing multiple commits into one.

Inicie-o com o último commit que você quer manter como está:

An editor will be fired up with all the commits in your current branch (ignoring merge commits), which come after the given commit. You can reorder the commits in this list to your heart’s content, and you can remove them. The list looks more or less like this:

As descrições on-line são puramente para o seu prazer; o comando git rebase não examinará eles, porém os nomes dos commits ("deadbee" e "fa1afe1" neste exemplo), portanto, não exclua ou edite os nomes.

Ao substituir o comando "pick" pelo comando "edit", é possível dizer ao comando git rebase para parar após aplicar este commit, para que seja possível editar os arquivos e/ou a mensagem do commit, alterar o commit e continuar com a reconstrução.

Para interromper um "rebase" (exatamente como um comando "edit" faria, mas sem fazer uma escolha seletiva de nenhum commit primeiro), use o comando "break".

Caso apenas queira editar a mensagem do commit para um commit, substitua o comando pick pelo comando reword.

Para eliminar um commit, substitua o comando "pick" por "drop" ou apenas exclua a linha coincidente.

If you want to fold two or more commits into one, replace the command "pick" for the second and subsequent commits with "squash" or "fixup". If the commits had different authors, the folded commit will be attributed to the author of the first commit. The suggested commit message for the folded commit is the concatenation of the first commit’s message with those identified by "squash" commands, omitting the messages of commits identified by "fixup" commands, unless "fixup -c" is used. In that case the suggested commit message is only the message of the "fixup -c" commit, and an editor is opened allowing you to edit the message. The contents (patch) of the "fixup -c" commit are still incorporated into the folded commit. If there is more than one "fixup -c" commit, the message from the final one is used. You can also use "fixup -C" to get the same behavior as "fixup -c" except without opening an editor.

O comando git rebase será interrompido quando o "pick" for substituído por "edit" ou quando um comando falhar devido aos erros da mesclagem. Quando você terminar de editar e/ou resolver os conflitos, será possível continuar utilizando git rebase --continue.

Como por exemplo, caso você queira reordenar os últimos 5 commits de maneira onde o que era HEAD~4 se torne o novo HEAD. Para conseguir isso, você chamaria o comando git rebase assim:

E mova o primeiro patch para o ramo da lista.

Convém recriar a mesclagem dos commits, por exemplo, caso tenha um histórico como este:

Suponha que queira reconstruir o lado do ramo ao lado começando em "A" para "Q". Verifique se o HEAD atual é "B" e chame

Reordering and editing commits usually creates untested intermediate steps. You may want to check that your history editing did not break anything by running a test, or at least recompiling at intermediate points in history by using the "exec" command (shortcut "x"). You may do so by creating a todo list like this one:

A reconstrução interativa será interrompida quando um comando falhar (ou seja, encerra com uma condição diferente de 0) oferecendo uma oportunidade para a correção do problema. Você pode continuar com o comando git rebase --continue.

The "exec" command launches the command in a shell (the default one, usually /bin/sh), so you can use shell features (like "cd", ">", ";" …​). The command is run from the root of the working tree.

This command lets you check that intermediate commits are compilable. The todo list becomes like that:

In interactive mode, you can mark commits with the action "edit". However, this does not necessarily mean that git rebase expects the result of this edit to be exactly one commit. Indeed, you can undo the commit, or you can add other commits. This can be used to split a commit into two:

Caso não tenha certeza absoluta que as revisões intermediárias são consistentes (elas compilam, passam no conjunto de testes, etc.), você deve usar o git stash para armazenar o commit das alterações que ainda não foram feitas após cada commit, teste e corrija o commit caso correções sejam necessárias.

Rebasing (or any other form of rewriting) a branch that others have based work on is a bad idea: anyone downstream of it is forced to manually fix their history. This section explains how to do the fix from the downstream’s point of view. The real fix, however, would be to avoid rebasing the upstream in the first place.

To illustrate, suppose you are in a situation where someone develops a subsystem branch, and you are working on a topic that is dependent on this subsystem. You might end up with a history like the following:

Caso a reconstrução da fundação do subsystem seja realizada contra o master, o seguinte acontece:

Caso agora continue o desenvolvimento normalmente e eventualmente mescle o topic para subsystem, os commits do subsystem permanecerão duplicados para sempre:

Such duplicates are generally frowned upon because they clutter up history, making it harder to follow. To clean things up, you need to transplant the commits on topic to the new subsystem tip, i.e., rebase topic. This becomes a ripple effect: anyone downstream from topic is forced to rebase too, and so on!

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

O comando de reconstrução interativa foi originalmente projetado para lidar com séries de patches individuais. Como tal, faz sentido excluir a mesclagem dos commits da lista de tarefas, pois o desenvolvedor pode ter mesclado o master atual enquanto trabalhava no ramo, apenas para redefinir todos os commits para master eventualmente (ignorando a mesclagem dos commits).

No entanto, existem razões legítimas pelas quais um desenvolvedor pode querer recriar as mesclagens dos commits: para manter a estrutura do ramo (ou a "topologia do commit") ao trabalhar em diversos ramos inter-relacionadas.

No exemplo a seguir, o desenvolvedor trabalha em um tópico no ramo que refatora a maneira como os botões são definidos, em outro tópico do ramo que utilize esta refatoração para implementar um botão "Relatar um bug". A saída do git log --graph --format=%s -5 pode ficar assim:

O desenvolvedor pode querer redefinir estes commits para um novo master enquanto mantém a topologia da ramificação. Quando se espera que o primeiro tópico do ramo que seja integrado ao` master` muito antes do segundo por exemplo. Para resolver os conflitos da mesclagem com as alterações para a classe DownloadButton que a transformou em master por exemplo.

This rebase can be performed using the --rebase-merges option. It will generate a todo list looking like this:

Ao contrário de uma reconstrução interativa regular, existem os comandos label, reset e merge além dos comandos pick.

O comando label associa um rótulo ao HEAD atual quando este comando for executado. Estes rótulos são criados como refs locais da árvore de trabalho (refs/rewritten/<label>) que serão excluídos quando a reconstrução terminar. Dessa forma, as operações da reconstrução em várias árvores de trabalho vinculadas ao mesmo repositório não interferem entre si. Caso o comando label falhe, este é imediatamente reagendado, com uma mensagem útil sobre como proceder.

O comando reset redefine o HEAD, o índice e a árvore de trabalho para a revisão específica. É semelhante a um comando exec git reset --hard <label>, porém se recusa a sobrescrever os arquivos que não sejam monitorados. Se o comando reset falhar, ele será imediatamente reagendado, com uma mensagem útil sobre como editar a lista de tarefas (normalmente acontece quando um comando reset foi inserido manualmente na lista de tarefas e contém um erro de digitação).

The merge command will merge the specified revision(s) into whatever is HEAD at that time. With -C <original-commit>, the commit message of the specified merge commit will be used. When the -C is changed to a lower-case -c, the message will be opened in an editor after a successful merge so that the user can edit the message.

If a merge command fails for any reason other than merge conflicts (i.e. when the merge operation did not even start), it is rescheduled immediately.

By default, the merge command will use the ort merge strategy for regular merges, and octopus for octopus merges. One can specify a default strategy for all merges using the --strategy argument when invoking rebase, or can override specific merges in the interactive list of commands by using an exec command to call git merge explicitly with a --strategy argument. Note that when calling git merge explicitly like this, you can make use of the fact that the labels are worktree-local refs (the ref refs/rewritten/onto would correspond to the label onto, for example) in order to refer to the branches you want to merge.

Observação: o primeiro comando (label onto) rotula a revisão onde os commits são refeitos; O nome onto é apenas uma convenção, como um aceno para a opção --onto.

Também é possível introduzir commits para mesclagem completamente novos, adicionando um comando no formato merge <merge-head>. Este formulário gera uma mensagem de commit provisória e sempre abre um editor para permitir que o usuário a edite. Pode ser útil quando por exemplo, um ramo de um tópico acaba resolvendo mais de um problema e quer ser dividido em dois ou mais ramos de tópico. Considere esta lista de tarefas:

O único commit nesta lista que não está relacionado ao CMake pode muito bem ter sido motivado ao trabalhar na correção de todos os erros introduzidos durante a mudança para o CMake, porém ele lida com um interesse diferente. Para dividir esse ramo em dois tópicos, a lista de tarefas pode ser editada desta maneira:

Parte do conjunto git[1]