Durante o processo de desenvolvimento de software é comum que ao criarmos mais código, possamos enviar ele para o repositório de código, assim os colegas podem acompanhar o que está sendo alterado e também você criar um backup de suas informação.
Mas surge uma dúvida na cabeça do programador: qual é o mínimo de código que deve criar antes de realizar um commit? Uma linha? Duas? Cem? Fica complexo definir isso, pois se criarmos muitos commits a nossa funcionalidade nova não fica atômica, mas se demorarmos para commitar e enviar para o repositório, corremos o risco de criar um commit grande demais para review, além é claro do risco de perder o código local.
Para ajudar nisso, o git possui uma funcionalidade muito interessante, o git squash, que permite que você agrupe seus commits já realizados, podendo assim criar commits mais organizados.
Vamos supor que você criou seu arquivo de teste unitário, comitou esta alteração e deseja já deixa-la no repositório remoto (na sua branch específica, é claro) como backup:
git add test_nova_funcionalidade.py git commit -m “Teste unitário da nova funcionalidade” git push origin nova_funcionalidade
Despois de criar os testes, obviamente você irá criar a funcionalidade:
git add nova_funcionalidade.py git commit -m “Nova funcionalidade implementada” git push origin nova_funcionalidade
Além disso, você descobriu que precisa ajustar um outro arquivo já existente, para dar suporte a sua alteração, no nosso caso, vamos ajustar nosso README.md:
git add README.md git commit -m “Alterado o README.md” git push origin nova_funcionalidade
Agora tudo está concluído, vamos ver como as coisas ficaram lá no Github:
Perceba que existem três commits, porém como a nossa funcionalidade é única, queremos criar algo atômico para agruapar estas alterações e neste ponto entra o git squash.
Iremos agrupar os commits reescrevendo o histórico de nossos últimos 3 commits, para isso precisaremos usar o comando:
git rebase -i HEAD~3
Nisto será aberto uma tela listando nossos últimos três commits:
pick b755797 Teste unitário da nova funcionalidade pick 8a7064e Nova funcionalidade implementada pick fdc8f9b Alterado o README.md
Rebase 8c0eaf4..fdc8f9b onto 8c0eaf4 (3 commands)
Iremos deixar apenas o primeiro da lista como está e iremos alterar o pick para squash:
pick b755797 Teste unitário da nova funcionalidade squash 8a7064e Nova funcionalidade implementada squash fdc8f9b Alterado o README.md
Assim salvamos a nossa alteração e abrirá uma nova tela onde podemos digitar uma nova mensagem (esta já virá com todas as mensagens dos commits anteriores, que podem ser apagados). Colocarei uma mensagem que resume tudo o que foi feito:
Criada nova funcionalidade
- Criado teste unitário
- Criada funcionalidade
- Alterado README.md
Agora salvamos e temos o nosso novo commit:
[detached HEAD 1543120] Criada nova funcionalidade Date: Sun Jan 6 22:09:46 2019 -0200 3 files changed, 3 insertions(+), 1 deletion(-) create mode 100644 nova_funcionalidade.py create mode 100644 test_nova_funcionalidade.py Successfully rebased and updated refs/heads/nova_funcionalidade.
Podemos fazer o push forçado (pois será necessário reescrever o histórico):
git push -f origin nova_funcionalidade
E agora ao verificar novamente no Github, vemos apenas um único commit com todas as alterações:
Assim o Pull Request fica bem mais simples, e caso necessário, você pode retornar a versão apenas um único commit.