GIT Rebase para Trabalhar numa Branch dependente de Outra Branch

-- start branch2 from branch1
git checkout branch1
git checkout -b branch2

-- make changes on branch2
git checkout branch2
git add file-changed
git commit -m "my commit message"

-- rebase branch2 whenever branch1 gets changed
git checkout branch2
git rebase branch1

-- finally rebase branch2 after branch1 was merged into master
git checkout master
git pull origin master
git checkout branch2
git rebase --onto master branch1 branch2

Trabalhando com as diversas técnicas modernas de desenvolvimento de sistemas como CI/CD, CleanCode, PMF entre outras os Web Devs frequentemente enfrentam o dilema de fragmentar ou não seus Pull Requests.

Para quem trabalha com o GIT segue aqui uma receita que achei interessante registrar. A receita é auto-explicativa não tem muito segredo; a sacada aqui é a sequência combinada dos comandos que já utilizamos em atividades diárias com o GIT.

Quer saber se funciona mesmo?

Funciona sim, finalmente tive oportunidade de testar num projeto recente e foi sucesso total, exceto pelo fato de eu ter produzido múltiplos commits o que não é permitido no meu ambiente de CI/CD.

Para resolver estes commits múltiplos bastou fazer um squash para unificá-los na branch final.

git checkout branch2
git reset --soft HEAD~2
git commit -m "new commit message"
git pull --rebase origin master --autostash
git push -f

Para evitar essa complicação final deveríamos fazer apenas commits complementares, assim logo após criar a branch2 a partir da branch1 somente performar commitamend:

-- make your changes on branch2 then commit amend
git checkout -b branch2
git add file-changed
git commit --amend

So, who’s gonna take the risk?

GIT CHECKOUT Para Restaurar um Único Arquivo já Comitado

git log
// encontre o hash da versão que você deseja retornar um arquivo
git checkout <commit hash> <caminho-completo-para-o-arquivo-desejado>
git status
git commit

Devs utilizando a metodologia “PMF” estão em constante evolução de seus códigos e muitas vezes podem acabar numa sinuca de bico e invariavelmente em algum momento podem querer reverter suas alterações.

Mas e se a reversão a ser feita envolve apenas um único arquivo e usar o git reset pode dar aquele medo de piorar as coisas?

Bom, nessas horas você pode fazer uso do git checkout mesmo, afinal este comando é bastante comum pois usamos este comando o tempo todo, então não haveria razão para ter medo de usá-lo. Haveria?

A sacada aqui é apenas combinar o git checkout com o hash do commit que tem a versão do arquivo a ser restaurado adicionando-se também o caminho completo para o arquivo desejado. A versão do arquivo então é baixada para a “working area” e depois de você verificar o conteúdo dele basta apenas comitar novamente o arquivo para o repositório.

É claro que você poderia alcançar o mesmo resultado com outros comandos GIT como o reset ou o revert. Mas se o git checkout faz este trabalho pra você com uma sintaxe extremamente limpa, pra que complicar?

Vale ressaltar que este fluxo o git checkout não irá funcionar para arquivos novos que acabaram de ser comitados, isto por que um arquivo novo não existirá em um commit hash anterior e no commit hash atual ele é o que é, um arquivo novo.

Nesta situação é recomendado o uso do git rm que irá funcionar perfeitamente para esta necessidade… eu já escrevi um artigo sobre git rm aqui no blog, recomendo dar uma olhada nele para maiores detalhes de uso.

Agora sem complicações, vai de git checkout bro! …ou de git rm quando for um arquivo novo.