Fiz um push sem checar as alterações do repositório, e agora?
Tags: git, development, braziliandevs
Published: 2023-09-14 01:04:55

#### **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.