GIT Reset Eliminando um Commit da sua Branch

-- before proceeding be sure working area is clean
git status 

-- eliminate commit and throw away all changes
git reset --hard HEAD~1

-- or if you want to reuse your changes
-- eliminate commit but keep changes at working area
git reset --soft HEAD~1

Em algumas situações acabamos por introduzir um commit indesejado numa branch. Então o que fazer?

Fácil, o RESET está aí pra isso mesmo.

Usando a opção –hard estamos indicando que as alterações desfeitas sejam jogadas fora, ou seja, você usa esta opção quando desistiu mesmo e quer recomeçar o trabalho do zero.

Já a opção –soft estamos indicando que as alterações desfeitas permaneçam nos arquivos da working area para que você possa ainda utilizá-los antes de um novo commit.

Vale lembrar que estamos sacando fora commits do topo da pilha. Na verdade podemos sacar vários commits de uma só vez mas sempre será a partir do topo e em sequência.

-- eliminate the top 5 commits in the stack at once
git reset --hard HEAD~5

Para sacar mais de um commit por vez basta ajustarmos o HEAD~{n} onde n é a quantidade de commits a serem removidos.

É isso, mais fácil que cortar manteiga quente!

GIT Reset Para Unificar Vários Commits em um Único Commit

git reset --soft HEAD~2 
git commit -m "new commit message"
git push -f

O jeito mais rápido para se unificar vários commits num único commit é usando o git reset. Pra quem não sabe o nome desta operação é SQUASH, mas o GIT não tem uma comando git squash como muitos podem pensar.

Apesar de muitos artigos desaconselharem o uso do RESET por vários motivos, esta sequência de comandos é inofensiva e muito fácil de realizar.

No exemplo acima basicamente o reset desfaz os últimos 2 commits indicados em HEAD~2 sendo que o –soft indica para manter os arquivos impactados na working area.

Na sequência basta realizar um novo commit com todos os arquivos contendo as alterações dos commits desfeitos. Uma nova mensagem precisa ser informada para este novo commit.

Simples, rápido e eficiente!

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?