7.13 Ferramentas do Git - Substituir (Replace)

Como já enfatizamos anteriormente, os objetos no banco de dados de objetos do Git são imutáveis, mas o Git fornece uma maneira interessante de fingir substituir objetos em seu banco de dados por outros objetos.

O comando replace permite especificar um objeto no Git e dizer "toda vez que você se referir a este objeto, finja que é um objeto diferente". Isto é mais comumente útil para substituir um commit no seu histórico por outro, sem ter que reconstruir todo o histórico com, digamos, o git filter-branch.

Por exemplo, digamos que você tenha um enorme histórico de código e deseje dividir o seu repositório em um histórico curto para novos desenvolvedores e um histórico muito maior e mais longo para pessoas interessadas em garimpar dados. Você pode enxertar um histórico no outro "substituindo" o primeiro commit da linha nova pelo último commit da antiga. Isto é ótimo porque significa que você não precisa realmente reescrever todos os commits do histórico novo, como você normalmente teria que fazer para juntá-los (já que a descendência afeta os SHA-1s).

Vamos tentar isso. Vamos pegar um repositório existente, dividi-lo em dois repositórios, um recente e um histórico, e então veremos como nós podemos recombiná-los sem modificar os valores de SHA-1 do repositório recente usando o replace.

Nós vamos usar um repositório simples com cinco commits simples:

Nós queremos quebrar isso em duas linhas de histórico. A primeira linha vai do commit um ao commit quatro - esta será a histórica. A segunda linha será composta apenas pelos commits quatro e cinco - esta será a de histórico recente.

Bom, criar o histórico histórico é fácil, nós podemos apenas colocar uma branch no histórico e depois dar um push desta branch para a branch master de um novo repositório remoto.

Agora nós podemos dar um push da nova branch history para a branch master do nosso novo repositório:

OK, nosso histórico está publicado. Agora a parte mais difícil é truncar (encurtar) nosso histórico recente para que ele fique menor. Nós precisamos de uma sobreposição para que possamos substituir um commit em um deles por um commit equivalente no outro, então nós vamos truncar isto deixando somente os commits quatro e cinco (fazendo com que o commit quatro se sobreponha).

É útil neste caso criar um commit base que tenha instruções de como expandir o histórico, assim os outros desenvolvedores saberão o que fazer se baterem no primeiro commit do histórico truncado e precisarem de mais. Então, o que vamos fazer é criar um objeto commit inicial, sendo o nosso ponto base com instruções, e então realizar um rebase nos commits remanescentes (quatro e cinco) em cima dele.

Para se fazer isso, precisamos escolher um ponto em que faremos a divisão, que para nós é o terceiro commit, que é o 9c68fdc no jargão do SHA. Assim, nosso commit base será baseado nesta árvore (tree). Nós podemos criar nosso commit base utilizando o comando commit-tree, o qual simplesmente apanha a tree (árvore) e nos devolve um brand new SHA-1 de objeto de commit e que não tem ascendência (parentless).

Agora que temos um commit-base, podemos fazer rebase do restante do histórico sobre ele com git rebase --onto. O argumento --onto será o SHA-1 que acabamos de receber de commit-tree, e o ponto do rebase será o terceiro commit (o pai do primeiro commit que queremos manter, 9c68fdc):

Muito bem, agora reescrevemos nosso histórico recente sobre um commit-base descartável que contém instruções para reconstituir todo o histórico, caso quiséssemos. Podemos fazer push desse novo histórico para um novo projeto; quando alguém clonar esse repositório, verá apenas os dois commits mais recentes e, em seguida, um commit-base com instruções.

Agora vamos assumir o papel de alguém que clona o projeto pela primeira vez e quer obter todo o histórico. Para obter os dados do histórico depois de clonar esse repositório truncado, essa pessoa teria de adicionar um segundo remote para o repositório histórico e fazer fetch:

Sendo desta forma o companheiro estaria retendo num braço de código dito master suas mais novas submissões (commits), mantendo as de enredo dantescas nesse que é o ramo nomeado de project-history/master.

A fim da união recíproca dos ditos arranjos, chame o git replace conjugando aquele commit tencionado em ser substituído com a peça do que em seu lugar fará a devida permuta. No presente ensaio o alvo de toda essa ação é aquele quarto commit abrigado na envergadura atrelada à branch master, que sairá afim do commit quarto advindo de project-history/master:

Agora, se você examinar o histórico do branch master, ele terá esta aparência:

Legal, não é? Sem precisar alterar todos os SHA-1s do upstream, conseguimos substituir um commit do histórico por outro completamente diferente, e todas as ferramentas comuns (bisect, blame etc.) funcionarão como esperado.

Curiosamente, ele ainda mostra 81a708d como o SHA-1, embora esteja usando os dados do commit c6e1e95 pelo qual o substituímos. Mesmo que você execute um comando como cat-file, ele mostrará os dados substitutos:

Lembre-se de que o pai real de 81a708d era nosso commit substituto (622e88e), e não 9c68fdce, como aparece aqui.

Outro aspecto interessante é que esses dados ficam armazenados em nossas referências:

Isso significa que é fácil compartilhar nossa substituição com outras pessoas, pois podemos fazer push dela para o servidor e elas podem baixá-la facilmente. Isso não é tão útil no cenário de enxerto de histórico que examinamos aqui (afinal, todos baixariam ambos os históricos; então, por que separá-los?), mas pode ser útil em outras circunstâncias.