Tudo o que você precisa saber sobre GIT
Tags: beginners, tutorial, learning, git
Published: 2024-02-12 14:30:00

Certamente você pode imaginar a importância de se versionar um código, para poder **reverter alterações**, **recuperar dados perdidos**, **entre outras possibilidades**. E aposto que você conhece alguém _(não eu hehe)_ que controla a versão dos seus arquivos criando cópias deles com nomes cada vez mais criativos...

![GIF simulando a duplicação de um arquivo com nomes direfentes. Exemplo: tcc, tcc-versãoFinal, etc.](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/kx97mjx9jesulods13se.gif)

Até 1972, provavelmente era assim que qualquer pessoa faria o controle de versão dos seus códigos também, antes do lançamento do **SCCS _(Source Code Control System)_**, um dos primeiros softwares de gerenciamento de versões **centralizados** que já foram lançados.

Mas não é o SCCS que nos interessa agora e sim o **GIT**, software de versionamento de código **distribuído** open-source que completa 20 anos do seu lançamento no ano que vem _(07/04/2005)_.

## Índice
* [1. O que é GIT?](#capitulo-1)
* [2. Como o GIT funciona?](#capitulo-2)
* [3. Instalando o GIT](#capitulo-3)
* [4. Configurando o GIT](#capitulo-4)
* [5. Iniciando um repositório local](#capitulo-5)
* [6. Trabalhando com GIT](#capitulo-6)
* [7. Conhecendo as branches](#capitulo-7)
* [8. Sincronizando com o repositório remoto](#capitulo-8)
* [9. Conclusão](#capitulo-9)
* [10. Referências](#capitulo-10)

## 1. O que é GIT? <a name="capitulo-1"></a>
GIT é um sistema de controle de versão **distribuído** open-source lançado em 2005, que foi desenvolvido por Linus Torvald _(isso mesmo, o criador do kernel do Linux)_.

Com o GIT, é possível **controlar as versões de um projeto** localmente _(na pasta de trabalho)_ e sincronizar todas as alterações para um repositório remoto _(no GitHub, por exemplo)_.

## 2. Como o GIT funciona? <a name="capitulo-2"></a>
Imagine um arquivo **físico** onde há uma pasta com todos os arquivos do projeto. Dessa forma, sempre que alguém precisar manipular um arquivo, é preciso pegá-lo, **removendo-o de dentro da pasta e retornando-o para a pasta após concluir o trabalho**. Assim, é **impossível** que duas pessoas trabalhem num mesmo arquivo, evitando totalmente possíveis conflitos.

**MAS NÃO É ASSIM QUE O GIT FUNCIONA!** _(ainda bem)_

Esse é o funcionamento de um sistema de versionamento **CENTRALIZADO**, no qual o usuário precisa realizar o **"check-out"** e **"check-in"** de arquivos, ou seja, sempre que alguém precisa trabalhar em um determinado arquivo é necessário realizar o "check-out" desse arquivo, **removendo-o do repositório**, e depois de concluído o trabalho, realizar o "check-in" do arquivo, **retornando-o para o repositório**.

![GIF simulando o funcionamento de um sistema de controle de versão centralizado.](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/vlwj7qzpzeyesqcg8pup.gif)

Em um sistema **DISTRIBUÍDO** como o **GIT**, é possível que várias pessoas acessem arquivos de um mesmo repositório remoto. Dessa forma, sempre que alguém precisar manipular um arquivo, basta **cloná-lo** _(ou clonar todo o repositório)_ localmente para sua máquina, e depois enviar as modificações de volta ao repositório remoto. Assim, é possível que **diversas pessoas trabalhem no mesmo projeto**, manipulando até mesmo os **mesmos arquivos**.

![GIF simulando o funcionamento de um sistema de controle de versão distribuído.](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/vxafv9z26zpc2y4w4z8d.gif)

Esse tipo de abordagem é o que permite a distribuição de grandes projetos **open-source**, com pessoas de diversas partes do mundo trabalhando em um mesmo projeto, gerenciando as modificações e possíveis conflitos _(sim, conflitos de merge podem acontecer aqui)_.

## 3. Instalando o GIT <a name="capitulo-3"></a>
Atualmente, **GIT** está disponível para os principais sistemas operacionais _(Windows, Linux, MacOs...)_ e a sua instalação é bem simples, podendo ser feita por **linha de comando** ou através do **instalador oficial** em [git-scm.com](https://git-scm.com/).

### 3.1 No Windows
Para instalar o GIT no Windows, basta acessar o site oficial e realizar o [download do instalador](https://git-scm.com/download/win).
Com isso, basta apertar **seguir as instruções** que tudo deve correr bem e será possível utilizar os comandos do GIT no seu terminal.

### 3.2 No Linux
Para o Linux, é possível instalar o **GIT** utilizando o **comando** abaixo:

```bash
sudo apt install git-all
```
Dessa forma, o **GIT** estará pronto para ser usado em seu terminal.

### 3.3 No MacOS
No Mac, a forma mais fácil de instalar o **GIT** é instalando o [Homebrew](https://brew.sh/) e então executando o **comando** abaixo no terminal:

```bash
brew install git
```

Assim, o GIT também ficará disponível para ser utilizado em seu terminal.

## 4. Configurando o GIT <a name="capitulo-4"></a>
Após a instalação, é importante **configurar** o **GIT** utilizando os comandos abaixo:

```bash
git config --global user.name "[username]"
# ex.: John Doe
```

```bash
git config --global user. email "[email@email.com]"
# ex.: johndoe@email.com
```

>Também é possível configurar usuários específicos para determinados repositórios locais removendo a tag `--global`.

## 5. Iniciando um repositório local <a name="capitulo-5"></a>
Com o **GIT** configurado, podemos **iniciar nosso repositório**.
Para isso, é possível **iniciar um novo repositório do zero ou clonar um repositório remoto existente**.

### 5.1 Iniciando do zero (git init)
Para iniciar um novo repositório, basta navegar até a **pasta raiz** que desejamos tornar um repositório e executar o comando abaixo:

```bash
git init
```

![Captura de tela de um terminal Linux executando o comando "git init", exibindo o resultado.](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/s0gk4uti8v71sprgiwx3.png)

Dessa forma, um diretório `.git` será criado dentro da pasta do projeto, que será **responsável pelo controle de versão** na pasta de trabalho desse repositório local.

### 5.2 Clonando um repositório (git clone)
Clonar um repositório remoto existente é tão fácil quanto iniciar um novo repositório do zero. Para isso, basta utilizar o comando `git clone` passando a **URL do repositório** à ser clonado como parâmetro dentro da pasta em que deseja clonar o repositório:

```bash
git clone [url-do-repositório-clonado]
```

![Captura de tela de um terminal Linux executando o comando "git clone", exibindo o resultado.](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/gfc4nzs7t3fpruyqjf17.png)

Dessa forma, todo o repositório sera **clonado** para sua máquina local, sendo **automaticamente atrelado ao repositório remoto de origem**.

>Em um repositório clonado não haverá necessidade de utilizar o comando `git remote` no futuro.

## 6. Trabalhando com GIT <a name="capitulo-6"></a>
Tendo o repositório local inicializado, é possível trabalhar em nosso projeto utilizando o controle de versão do **GIT** localmente.

Dentro do nosso **repositório local**, podemos criar os arquivos necessários para o nosso projeto, mas eles **não serão sincronizados automaticamente pelo GIT**, para isso é necessário que informemos quando houver mudanças para serem versionadas.

Assim, podemos **manipular** os arquivos como quisermos e, **após concluir as alterações** desejadas, **enviar os arquivos atualizados para o GIT**.

Para isso, é importante entender que existe um **fluxo infinito** (sim, infinito) de **3 estágios** no controle de versões:             

```
                    MODIFY -> STAGE -> COMMIT
```

* **MODIFY:** Primeiro estágio do controle de versões, aqui são colocados os **arquivos que sofreram alguma alteração** comparada à última versão disponível.
  
* **STAGE:** Segundo estágio do controle de versões, aqui são colocados os **arquivos modificados que queremos adicionar** ao próximo commit.
  
* **COMMIT:** Estágio final do controle de versões, quando **confirmamos as modificações feitas**, enviando os arquivos modificados que estavam em stage para o repositório local.

Com os arquivos commitados, temos uma **nova versão** disponível no repositório local, que pode novamente sofrer alterações, passando novamente para _"modified"_, ter essas novas alterações colocadas em _"stage"_ e novamente _"commitadas"_, confirmando uma nova versão e assim por diante _(e por isso "infinito" lol)_.

>Um commit não exclui a versão antiga dos arquivos modificados, apenas inclui a nova versão com um apontamento para a última versão disponível, mantendo assim o rastreamento das versões de cada arquivo rastreado pelo GIT.

### 6.1 Adicionando e commitando (git add e git commit)
Apesar de parecer complexo, executar o fluxo de versionamento é **bem simples**. Após concluir as modificações desejadas, **adicionamos os arquivos modificados que desejamos commitar em stage**:

```bash
git add [nome-do-arquivo]
```

>`git add -A` -> adiciona todos os arquivos modificados para stage de uma vez.
>
>`git add *.[extensão-do-arquivo]` -> adiciona todos os arquivos modificados com a extensão especificada para stage de uma vez (ex.: `git add *.html`).

É possível verificar o **status** atual do nosso repositório a qualquer momento utilizando o comando `git status`:

![Captura de tela de um terminal Linux executando o comando "git status", exibindo o resultado.](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/k5cbiaa1hfv6e9s0kdv0.png)

Perceba que, ao executar o `git status` dentro do repositório **após criar um novo arquivo**, o novo arquivo é exibido como _"Untracked"_. Isso significa que esse arquivo é **novo** e ainda precisa ser adicionado à algum commit para que seja **rastreado** pelo **GIT**.

>É possível fazer com que o GIT ignore determinados arquivos ou pastas dentro do repositório. Para isso basta adicionar um arquivo à pasta raiz chamado `.gitignore` e, dentro dele, destacar o nome dos arquivos ou pastas que devem ser ignorados.
>
>ATENÇÃO: Arquivos e pastas ignorados não aparecem mais no rastreamento do GIT, nem mesmo como "Untracked". Para retornar o rastreamento basta apagar os nomes do arquivo `.gitignore`.

Para incluir um arquivo, podemos executar o comando `git add` que vimos antes com o nome do arquivo que desejamos adicionar _("index.html" nesse caso)_:

![Captura de tela de um terminal Linux executando o comando "git add" e, em seguida, "git status", exibindo o resultado.](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/efz8bakcop88psyhgd13.png)

Dessa forma, ao executar novamente o `git status` podemos perceber que o novo arquivo foi adicionado ao _"stage"_ e está **finalmente pronto para ser enviado no nosso próximo commit**, que pode ser feito utilizando o comando abaixo:

```bash
git commit -m "[mensagem-descritiva]"
```

>COMMITS possuem ID's (hash) únicos e são **IMUTÁVEIS**, ou seja, não podem ser modificados após confirmados.
>
>`git commit -a` -> realiza o commit direto, adicionando todos os arquivos modificados em stage e realizando o commit.

**Após realizar o commit com sucesso**, ao executar o `git status` percebemos que **não há mais arquivos modificados para serem enviados**, uma vez que todas as modificações foram efetivamente salvas no nosso repositório local com o último **commit**.

![Captura de tela de um terminal Linux executando o comando "git commit" e, em seguida, "git status", exibindo o resultado.](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/l9rfaeoavyjjp31dlkkk.png)

Ainda é possível **comprovar as mudanças realizadas** ao rever o log de commits do repositório, utilizando o comando `git log`, que mostra alguns metadados de todos os commits realizados como o código hash, branch, autor, data, etc.

![Captura de tela de um terminal Linux executando o comando "git log", exibindo o resultado.](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/3yb8uv7ur5g8c0w2pzgq.png)

Todo esse processo pode ser repetido para adicionar novos arquivos que sejam necessários ao seu projeto, modificá-los e enviá-los ao repositório local através de commits.

![GIF simulando a realização de diversos commits em uma branch do GIT.](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2uez3henix8kchperuw8.gif)

>`git log -N` -> exibe o log dos últimos N commits.
>
>`git log [branch-A] [branch-B]` -> exibe o log dos commits que estão na "branch-B" mas não estão na "branch-A".
>
>`git log --follow [nome-do-arquivo]` -> exibe o log dos commits que alteraram o arquivo especificado, mesmo que ele tenha mudado de nome.
>
>`git diff` -> lista as modificações feitas em relação à última versão disponível no repositório.
> 
>`git diff [nome-do-arquivo]` -> lista as modificações feitas no arquivo especificado em relação à sua última versão disponível no repositório.

### 6.2 Desfazendo mudanças antes e depois do commit
**Antes de realizar um commit**, todas as mudanças feitas no repositório local podem ser desfeitas, ou alteradas, mas **após realizar o commit, não é possível alterá-lo**. Isso porque commits são **objetos imutáveis**, ou seja, é impossível editar ou alterar as informações de um commit realizado.

Ainda assim, **é possível realizar novos commits** que desfazem alguma alteração, ou corrigem informações incorretas em commits anteriores. Para ambos os casos, podemos utilizar um dos comandos listados abaixo:

```bash
git checkout -- [nome-do-arquivo]
# Descarta as mudanças feitas no arquivo local, antes do commit (ação irreversível)
```

```bash
git reset --hard HEAD
# Descarta as mudanças feitas em um arquivo que está em stage, antes do commit
```

```bash
git reset --hard HEAD~1
# Descarta o último commit realizado no repositório local (somente o último commit)
```

```bash
git commit --amend
# Realiza um novo commit, substituindo o último commit feito no repositório local
```

```bash
git revert [hash-do-commit]
# Realiza um novo commit revertendo as alterações do commit especificado
```

## 7. Conhecendo as branches <a name="capitulo-7"></a>
Uma **branch** nada mais é do que uma **ramificação** do repositório e, até agora, todas as ações foram realizadas na branch `master/main`.

>Por padrão, a primeira branch criada no repositório é a branch `master/main`, que é a branch principal do repositório.

### 7.1 Pra que servem as branches?
A princípio pode não parecer grande coisa, mas as **branches dão um poder enorme pro desenvolvimento** do projeto.

Imagine que estamos desenvolvendo uma plataforma web e queremos **testar uma nova feature**, mas nosso repositório já está sendo **hospedado ou compartilhado** com outras pessoas e qualquer alteração problemática pode causar uma péssima experiência à essas pessoas. O que podemos fazer?

Se você pensou em **duplicar** a pasta do projeto, criando uma **"versão de testes"**, você acertou! Bom, em partes...

Com o **GIT**, é possível fazer algo parecido utilizando as **branches**. Como elas são **ramificações**, podemos simplesmente **criar uma nova branch, chamada de "teste"** _(por exemplo)_, e assim teremos uma versão do nosso projeto em uma branch totalmente **isolada**, pronta pra ser revirada **sem qualquer risco de impactar a branch principal**.

![GIF simulando a criação de uma nova branch com novos commits sendo realizados nela.](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/fhasdypu3ey3dq056eca.gif)

### 7.2 Criando branches (git branch)
Criar uma **branch** significa criar uma cópia paralela do repositório que pode ser trabalhada independentemente, sem impactar a branch `master/main`. Para isso, basta utilizar o comando abaixo:

```bash
git branch [nome-da-branch]
```

>Executar o comando `git branch` sem um nome exibe a lista de branches disponíveis no repositório, com um "\*" na branch que está sendo utilizada atualmente.

Antes de executar o comando `git branch teste`, o comando `git branch` retornava somente a branch `master`.

![Captura de tela de um terminal Linux executando o comando "git branch", criando uma nova branch e exibindo o resultado.](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/zf4svh3t1bohyyy3jcvx.png)

Após criar uma nova branch, é possível alternar entre as branches disponíveis utilizando o comando abaixo:

```bash
git checkout [nome-da-branch]
```

Após executar o comando `git checkout teste`, podemos ver que a **branch ativa é alternada**. A partir desse momento **todo o trabalho commitado estará sendo enviado para a branch `teste`** do repositório, sem impactar a branch `master/main`.

![Captura de tela de um terminal Linux executando o comando "git checkout", alternando a branch ativa e exibindo o resultado.](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/jvk5byfkhrw271htk63g.png)

>É possível criar quantas branches forem necessárias e podemos interagir com as branches criadas utilizando os comandos abaixo:
>
>`git checkout -b [nome-da-branch]` -> cria uma nova branch com o nome especificado e já alterna para ela.
>
>`git branch -d [nome-da-branch]` -> exclui a branch especificada.
>
>`git branch -m [novo-nome]` -> altera o nome da branch atual para o nome especificado.

### 7.3 Combinando branches (git merge)
**Quando finalizamos o trabalho** em uma **branch diferente** e temos segurança de que as alterações feitas não ocasionaram problemas no código, **podemos mergear** _(combinar)_ a branch atual com a branch `master/main`, **aplicando todas as mudanças da branch atual à branch principal do repositório**.

Para realizar o **merge** de uma branch à outra, devemos **alternar para a branch que vai receber as alterações** e utilizar o comando abaixo:

```bash
git merge [nome-da-branch]
# faz o merge da branch especificada na branch atual
```

Nos nossos exemplos, como estamos na branch `teste`, **devemos alternar para a branch `master`** utilizando o comando `git checkout` e então executar o comando `git merge` com o nome da branch que desejamos combinar _("teste", nesse caso)_

![Captura de tela de um terminal Linux executando o comando "git checkout", alternando para a branch master e, em seguida, "git merge", exibindo o resultado.](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/o05mis8hmqxvji3b6ida.png)

Dessa forma, todo o trabalho feito na branch `teste` _(a criação do arquivo `style.css`, nesse caso)_ será combinado com a branch `master`.

![GIF simulando o processo de merge entre duas branches](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/aj66touqdivfszcygj9j.gif)

### 7.4 Conflitos no merge
Combinando diferentes branches com o `git merge` podemos nos deparar com alguns **conflitos** nos casos em que **um ou mais arquivos tenham sido alterados nas mesmas linhas** e a combinação não pode ser realizada de maneira **automática**.

![Captura de tela de um terminal Linux executando o comando "git merge", retornando alerta de conflito.](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/d29kwtdbo6v3ygo0g8ug.png)

Nesses casos, podemos executar o comando `git status` para verificar **quais arquivos** estão conflitando.

![Captura de tela de um terminal Linux executando o comando "git status" após o alerta de conflito no merge.](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ecgflogjezg7tqagnxca.png)

Será necessário **resolver os conflitos** antes de prosseguir com o merge, definindo quais alterações devem prevalecer ou refazendo as alterações para que sejam mutuamente comportadas. Para isso, **o próprio GIT insere marcações dentro dos arquivos conflitantes** que auxiliam a resolução.

![Captura de tela do arquivo conflitante aberto em um editor de texto exibindo as marcações criadas pelo GIT para auxiliar na resolução dos conflitos](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/5xkf28erxmwm48riwro5.png)

Após resolver os conflitos, basta recolocar os arquivos modificados em stage, realizar o commit das novas versões sem conflitos e executar novamente o comando `git merge` que tudo deve ser combinado sem maiores problemas.

## 8. Sincronizando com o repositório remoto <a name="capitulo-8"></a>
Sabemos que é possível **relacionar o nosso repositório local à um repositório remoto** para sincronizar todo o nosso trabalho remotamente e mantê-lo sempre **atualizado**.

Para isso, utilizaremos o comando `git push`, que **envia todos os commits do repositório local para o repositório remoto**, mas antes, precisamos **configurar um repositório remoto apropriado**.

### 8.1 Configurando um repositório remoto
Iniciar um **repositório remoto** é bastante simples. Aqui vamos utilizar o **GitHub** para isso.

Primeiro, devemos **iniciar um novo repositório vazio** em nossa conta do GitHub _(apenas escolhendo um nome e clicando em "Criar repositório")_:

![Captura de tela da página de criação de repositórios no GitHub.](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/rv86b3tupeadctbuhl4a.png)

Após isso, precisamos **configurar a relação entre o repositório remoto e o repositório local**, executando o comando abaixo dentro do nosso repositório local:

```bash
git remote add origin [url-do-repositorio-remoto]
```

![Captura de tela de um terminal Linux executando o comando "git remote", exibindo o resultado.](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/63m0nfymn1tidgtrodlm.png)

>`git remote -v` -> exibe a URL do repositório remoto conectado ao repositório local atualmente.

Com o repositório remoto **conectado**, devemos **alterar o nome da nossa branch** `master/main` local para "main" com o comando `git branch -m main` _(ignorar se a sua branch local já se chamar `main`)_:

![Captura de tela de um terminal Linux executando o comando "git branch", renomeando a branch "master" para "main" e exibindo o resultado.](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/aon7j7qsa26wkb56hjti.png)

>É importante que a branch principal do repositório local tenha o mesmo nome da branch principal do repositório remoto ao qual vamos realizar o push.

Finalmente, após cumprir os passos acima, podemos **sincronizar** nosso trabalho local com o repositório remoto pela primeira vez utilizando o comando abaixo:

```bash
git push -u origin main
```

![Captura de tela de um terminal Linux executando o comando "git push", exigindo autenticação do GitHub.](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/8tuxzcjceamo062qkhuq.png)

Ao executar o comando `git push -u origin main` pode ser necessário informar suas **credenciais do GitHub** _(usuário e token de acesso)_.

>Se você não sabe o que é um **token de acesso do GitHub**, ou ainda não tem seu token de acesso configurado, [clique aqui](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens#creating-a-personal-access-token-classic).
>
>Também é possível contornar isso configurando a **autenticação com o CLI do GitHub**. Saiba como [clicando aqui](https://docs.github.com/en/get-started/getting-started-with-git/caching-your-github-credentials-in-git).

Após **autenticar**, o `git push` deve ser executado com sucesso, sincronizando todos os commits do repositório local com o repositório remoto.

![Captura de tela de um terminal Linux exibindo a continuação do comando "git push" após a autenticação do GitHub.](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/yiid2ip61vqvtk860pa3.png)

![Captura de tela do repositório remoto no GitHub após receber o "git push" com os novos arquivos.](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/vgpzamg4umcx8xk1taso.png)

### 8.2 Git push depois da primeira vez (git push)
Depois de passar por todas as etapas acima, **novas sincronizações** podem ser realizadas somente utilizando o comando `git push`, sem que haja necessidade de passar qualquer parâmetro, como vemos abaixo.

![Captura de tela de um terminal Linux executando os comandos "git status", "git commit" e "git push", realizando um novo commit com envio das atualizações ao repositório remoto.](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/exa9y8e2ndprwx71ovvi.png)

![Captura de tela do repositório remoto no GitHub após receber as novas atualizações.](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/zm9pj2y4g9pi37y7hbgr.png)

>Nesse caso, a autenticação necessária para realizar o `git push` foi contornada utilizando o **CLI do GitHub**. Saiba como [clicando aqui](https://docs.github.com/en/get-started/getting-started-with-git/caching-your-github-credentials-in-git).

### 8.3 Atualizando o repositório local (git pull)
Com um repositório remoto **distribuído**, é possível que alterações sejam feitas **remotamente** _(diretamente no repositório remoto)_, fazendo com que nosso repositório local fique **desatualizado**.

Por isso, é muito importante **atualizar o repositório local**, sincronizando quaisquer mudanças existentes no repositório remoto, **garantindo que o código local esteja sempre em sua última versão disponível no repositório remoto**. Para isso, podemos utilizar o comando abaixo:

```bash
git pull
```

Imagine que um **novo arquivo** `README.md` foi criado **diretamente no repositório remoto** e, com isso, nosso repositório local está desatualizado.

![Captura de tela do repositório remoto com um novo arquivo "README.md" adicionado remotamente.](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ciyaqur9kk7eejebcfqf.png)

Dentro do repositório local, podemos **sincronizar** as alterações do repositório remoto com o `git pull`.

![Captura de tela de um terminal Linux executando o comando "git pull", atualizando o repositório local com as novas mudanças do repositório remoto.](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/etfhi8pxgbi5e34sydtz.png)

>As primeiras 7 linhas retornadas ao executar o comando `git pull` são resultado do comando `git fetch`. Ou seja, ao executar o comando `git pull` sem executar o comando `git fetch` previamente, o GIT executa ambos em conjunto para recuperar as atualizações do repositório remoto e sincronizá-las no repositório local.
>
>`git fetch` -> Recupera as atualizações do repositório remoto, mas não sincroniza o repositório local (necessita do `git pull`)

## 9. Conclusão <a name="capitulo-9"></a> 
Tudo isso nos traz a certeza de que o GIT é um sistema de controle de versão necessário no dia a dia de um programador, e conhecer seus principais comandos e utilidades pode ser o divisor de águas em nossa senioridade técnica.
Por fim, com os repositórios locais e remotos sincronizados e atualizados e com tudo o que aprendemos até agora, estamos prontos para seguir em frente com a praticidade desse incrível sistema de controle de versão.

## 10. Referências <a name="capitulo-10"></a>
* [Documentação oficial do GIT](https://git-scm.com/docs/git#_git_commands)
* [GIT: Mini Curso para Você Sair do Zero! (Aprenda em 45 Minutos) - Codigo Fonte TV](https://youtu.be/ts-H3W1uLMM?si=-hKGkUmwgT2lZJwy)

---
_Publicado originalmente em Inglês:_
[Everything you need to know about GIT](https://dev.to/basement/everything-that-you-need-to-know-about-git-2440)