*Este artigo foi escrito em conjunto com @donadonf *
Dentro de uma equipe de desenvolvimento nos deparamos com algumas demandas que são desenvolvidas por pares, alguns casos utilizam até a mesma branch para desenvolver a tarefa e fazem com que os desenvolvedores trabalhem 2 habilidades muito importantes: A comunicação e o versionamento de código. Neste artigo iremos tratar de uma situação que pode ser comum, podemos chamá-la de “Fiz um push e não sabia que a branch havia mudado, e agora?”.
Ao tentar fazer um push, provavelmente recebeu de volta uma mensagem indicando um conflito de branches, sendo a branch local em que está trabalhando e a branch remota, para onde irá o commit feito.
[rejected] master -> master (fetch first)
error: failed to push
Bom, teremos um longo caminho pela frente, mas fique tranquilo porque há uma solução!
Primeiramente, devemos verificar os commits que já estão na branch remota e qual o nosso status em relação a ela, para isso podemos executar o comando:
git status
Receberá uma informação sobre o status das branch em que está trabalhando, dessa forma:
On branch nome-da-branch
Your branch and 'origin/nome-da-branch' have diverged,
and have 1 and 1 different commits each, respectively.
Isso indica que sua branch local está com um commit a ser enviado, mas está com um commit atrasado em relação a branch remota, nesse cenário é necessário puxar os dados da branch remota antes de realizar o push para que não tenha um conflito de versões de código.
Começaremos a solução do conflito entre as branches checando os logs dos commits feitos com o comando:
git log
Vamos pegar o ID do último commit feito, porque aqui estaremos visualizando um histórico dos commits feitos. Com esse ID iremos executar um hard reset na branch atual e retirar o commit do HEAD com outro comando, então a sequência de comandos será a seguinte:
git reset --hard ID-do-commit
git reset HEAD~1
Novamente, vamos checar o status das versões que estamos trabalhando com comando git status, veremos que alguns arquivos estão marcados como Changes not staged for commit, isso significa que o commit foi resetado corretamente e as alterações feitas não foram perdidas. Devemos então armazenar essas mudanças dentro do stash para que possamos fazer o commit mais tarde com o comando:
git stash
Caso a operação ocorra bem, a mensagem será a seguinte:
Saved working directory and index state WIP on nome-da-branch: ID-do-commit-atual-da-branch
Devemos então executar o comando que irá mostrar a quantidade de arquivos que estão salvos no último stash feito.
git stash show
Como os arquivos estarão salvos no stash e branch terá voltado ao mesmo estágio da branch remota, podemos dar sequência ao procedimento padrão de um commit. Iremos checar o status da branch remota com o git status e depois executar um git pull para receber as alterações feitas na branch remota.
Por fim, podemos retirar os arquivos do stash porque iremos utilizá-los agora:
git stash pop
Isso irá trazer de volta as alterações feitas no commit que não conseguimos realizar o push. Caso esteja apavorado com a situação, poderá repetir o fluxo de visualizar o status da branch remota com git status e ver se há mais atualizações, poupando uma possível dor de cabeça. Caso não tenha nenhuma alteração, podemos seguir com o commit normalmente:
git commit -m "feat: texto-do-commit"
git push
Dessa forma, podemos solucionar os conflitos de versões de uma forma simples e objetiva utilizando apenas o terminal do git.
É chegado o grande momento, podemos dormir tranquilos com as versões atualizadas e organizadas em nossas respectivas branches.
Top comments (1)
Muito bom! Eu gosto de usar o
git logcom a flag--oneline