Git e GitHub

Todo mundo que já escreveu um trabalho no computador conhece a pasta com trabalho.docx, trabalho_v2.docx, trabalho_final.docx e trabalho_final_AGORA_VAI.docx. Funciona, mal e mal, enquanto se trabalha sozinho. Quando duas pessoas mexem nos mesmos arquivos, o método desmorona: alguém sobrescreve o trabalho do outro, ninguém sabe qual é a versão boa, e não há como voltar atrás. O Git existe para resolver exatamente esse problema, e o GitHub para levar essa solução para a internet, onde o time inteiro alcança. Este material cobre o caminho completo: instalar, versionar localmente, publicar, colaborar e resolver o conflito que inevitavelmente aparece.

1. Por que controlar versões

Imagine um caderno em que cada anotação nova apaga a anterior. É assim que um arquivo funciona por padrão: ao salvar, a versão anterior deixa de existir. Renomear cópias (v1, v2, final) é uma tentativa manual de contornar isso, e tem três limitações sérias:

• Não se sabe o que mudou de uma versão para outra, apenas que mudou
• Não se sabe por que mudou, nem quem fez a alteração
• Não há integração: se duas pessoas editam cópias diferentes, juntar tudo é trabalho manual e arriscado

Um sistema de controle de versão resolve os três pontos. Ele guarda o histórico completo do projeto, registra autor, data e uma mensagem explicando cada mudança, e sabe combinar alterações feitas por pessoas diferentes.

A escala do problema fica clara em projetos grandes: o código do Google tem cerca de 2 bilhões de linhas. Sem uma ferramenta que organize quem mudou o quê e quando, nada disso seria administrável.

2. O que é o Git

O Git é um sistema de controle de versão de arquivos. Ele acompanha todas as alterações feitas em um diretório e permite que várias pessoas trabalhem no mesmo projeto ao mesmo tempo, sem que uma sobrescreva o trabalho da outra.

Três características importantes:

• Foi criado em 2005 por Linus Torvalds, o mesmo criador do Linux
• É open source e gratuito
• É um programa instalado na sua máquina, que roda no terminal

Esse último ponto costuma causar confusão: o Git não é um site nem um serviço. Ele funciona inteiramente no seu computador, inclusive sem internet.

3. O que é o GitHub

O GitHub é um serviço web que hospeda repositórios Git na internet e acrescenta funcionalidades em volta deles.

• Permite hospedar projetos gratuitamente, públicos ou privados
• Concentra boa parte dos softwares, frameworks e bibliotecas de código aberto
• Pertence à Microsoft desde 2018
• Funciona também como uma rede social de desenvolvedores: perfis, seguidores e contribuições visíveis

A distinção entre os dois é a fonte mais comum de confusão no começo:

O Git funciona perfeitamente sem o GitHub. O contrário não existe: o GitHub hospeda repositórios Git.

Três comandos ligam um ao outro, e vale memorizar o sentido de cada um:

• push: envia os commits do seu computador para o GitHub
• pull: traz para o seu computador os commits que estão no GitHub
• clone: copia um repositório do GitHub para a sua máquina, pela primeira vez

4. Instalando e configurando

No Windows, o Git é baixado em git-scm.com e instalado com as opções padrão do instalador. Uma opção merece atenção: mantenha marcada a Git Credential Manager, que vem selecionada por padrão e será responsável por guardar seu login do GitHub mais adiante.

Depois de instalado, clicar com o botão direito dentro de uma pasta e escolher Git Bash Here abre o terminal já posicionado naquele diretório.

Antes do primeiro uso, é preciso dizer ao Git quem você é. Essa informação será gravada em cada commit que você fizer, identificando a autoria. Basta configurar uma vez por máquina:

git config --global user.name "seu NOME"
git config --global user.email "seu EMAIL"

O --global indica que a configuração vale para todos os repositórios daquele computador, e não apenas para o projeto atual.

Vale configurar também o nome do branch inicial, para que novos repositórios nasçam com main, o mesmo nome que o GitHub utiliza: git config --global init.defaultBranch main. Sem isso, dependendo da versão instalada, o Git pode criar o branch como master, e os comandos que mencionam main falharão.

5. As áreas de um repositório

Esta é a ideia central do Git, e entendê-la evita a maior parte da confusão com os comandos. Um arquivo não vai direto do seu editor para o histórico: ele passa por áreas distintas, e cada comando move o arquivo de uma para outra.

A staging area costuma parecer burocracia desnecessária no começo, mas tem uma razão de ser: ela permite escolher quais alterações entram em cada commit. Se você mexeu em cinco arquivos mas quer registrar apenas dois deles agora, é o git add que faz essa separação.

Uma analogia útil: o git add é separar os objetos que vão aparecer na foto; o git commit é tirar a foto e guardá-la no álbum, com uma legenda.

6. O fluxo local

Vamos acompanhar o ciclo completo em um exemplo: uma pasta site-receitas, com um arquivo receitas.html dentro.

git init

Dentro da pasta do projeto, o primeiro comando transforma o diretório comum em um repositório Git:

git init

A partir desse momento, o Git passa a acompanhar tudo o que acontece naquele diretório e em seus subdiretórios.

git status

O git status responde à pergunta “como estão as coisas agora?”. É o comando que mais se usa no dia a dia, e vale rodá-lo a cada passo:

git status

On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        receitas.html

nothing added to commit but untracked files present

O termo Untracked significa que o Git enxerga o arquivo, mas ainda não acompanha suas mudanças. Ele está na pasta, e não no controle de versão.

git add

Para que o Git passe a rastrear o arquivo, e para incluí-lo no próximo commit:

git add receitas.html
git status

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
        new file:   receitas.html

A mudança de Untracked files para Changes to be committed mostra que o arquivo saiu do workspace e entrou na staging area.

git commit

O commit grava no histórico tudo o que está na staging area, junto de uma mensagem que explica a alteração:

git commit -m "Adiciona a página de receitas"

[main (root-commit) 7b3ab1a] Adiciona a página de receitas
 1 file changed, 10 insertions(+)

A mensagem é obrigatória, e não é formalidade: daqui a seis meses, ela será a única pista sobre o motivo daquela mudança. Mensagens como “alterações” ou “teste” não ajudam ninguém, inclusive você mesmo.

git log

Para consultar o histórico gravado:

git log

commit 7b3ab1a8d5a94ce490bfa57670da14d9687f16c5 (HEAD -> main)
Author: seu-nome <[email protected]>
Date:   Tue Nov 3 12:20:08 2026 -0300

    Adiciona a página de receitas

Cada commit tem um identificador único (aquela sequência longa de caracteres), além de autor, data e mensagem. É esse identificador que permite ao Git voltar a qualquer ponto da história do projeto.

Alterações feitas depois de um commit precisam passar pelo mesmo caminho: editar, git add, git commit. Um git commit sem git add anterior não registra nada, porque a staging area está vazia, e o Git avisa exatamente isso.

7. Publicando no GitHub

Até aqui, todo o histórico existe apenas na sua máquina. Para que outras pessoas vejam o projeto, ou simplesmente para ter uma cópia segura fora do seu computador, ele precisa ser publicado.

Criando o repositório remoto

No GitHub, o botão New repository cria o repositório vazio. Ao criá-lo para receber um projeto que já existe localmente, deixe as caixas de README, .gitignore e licença desmarcadas: elas criariam commits no repositório remoto, e isso complicaria o primeiro envio.

Conectando o local ao remoto

O repositório local ainda não sabe que o remoto existe. O comando abaixo faz a ligação:

git remote add origin https://github.com/seu-usuario/site-receitas.git

O nome origin é apenas um apelido para aquela URL. Por convenção, é o apelido dado ao repositório remoto principal, e será usado nos comandos seguintes no lugar do endereço completo.

Autenticação

No primeiro envio, uma janela do navegador se abre pedindo login. Esse é o Git Credential Manager, instalado junto com o Git. Depois de fazer login com a conta do GitHub, as credenciais ficam guardadas naquela máquina, e o processo não se repete.

git push

Finalmente, o envio dos commits:

git push -u origin main

O -u (de upstream) vincula o branch local ao branch remoto. Feito isso uma vez, os envios seguintes precisam apenas de:

git push

8. Clonar em vez de começar do zero

O fluxo das seções anteriores parte de uma pasta vazia: é o caso de um projeto novo, iniciado por você. No dia a dia, porém, essa é a situação menos comum. Ao entrar em uma empresa ou em um projeto em grupo, o repositório quase sempre já existe, criado por outra pessoa.

git clone https://github.com/usuario/site-receitas.git

O git clone faz três coisas de uma vez: baixa todos os arquivos, baixa todo o histórico de commits, e configura o origin automaticamente. Não é preciso rodar git init nem git remote add origin depois dele.

A partir daí, o ciclo é o mesmo de sempre: editar, git add, git commit, git push.

9. Trabalhando com outras pessoas

Quando duas pessoas trabalham no mesmo repositório, surge uma situação nova: o repositório remoto pode conter commits que você ainda não tem. É para isso que existe o git pull:

git pull

O pull é o oposto do push: traz para a sua máquina os commits que já estão no GitHub e que você ainda não possui.

O hábito recomendado é simples: dar pull antes de começar a trabalhar e antes de dar push. Isso reduz bastante a chance de conflitos.

Se você tentar enviar commits sem ter trazido antes os que já estão no remoto, o Git recusa o envio:

! [rejected]        main -> main (fetch first)
error: failed to push some refs
hint: Updates were rejected because the remote contains work that you do not
hint: have locally. ... integrate the remote changes (e.g. 'git pull ...')

Isso não é um erro seu: é uma proteção. Aceitar esse envio significaria descartar o trabalho da outra pessoa. A mensagem indica a solução, que é rodar git pull primeiro.

10. Conflitos de merge

Na maior parte das vezes, o git pull junta as alterações sozinho. Se uma pessoa editou o arquivo A e outra editou o arquivo B, não há ambiguidade: o Git combina os dois.

O conflito acontece em uma situação específica: quando duas pessoas alteram a mesma linha do mesmo arquivo, partindo da mesma versão original. Aí o Git não tem como decidir qual das duas versões é a correta, porque essa é uma decisão humana. Em vez de escolher por conta própria, ele para e pede ajuda.

Como o conflito aparece

O terminal avisa com a palavra CONFLICT:

Auto-merging receitas.html
CONFLICT (content): Merge conflict in receitas.html
Automatic merge failed; fix conflicts and then commit the result.

E o arquivo em questão passa a conter marcadores delimitando as duas versões:

<<<<<<< HEAD
<h1>Receitas da vovó</h1>
=======
<h1>Livro de receitas</h1>
>>>>>>> origin/main

A leitura dos marcadores é direta:

• Entre <<<<<<< HEAD e ======= está a sua versão local
• Entre ======= e >>>>>>> origin/main está a versão que veio do remoto

Como resolver

Resolver um conflito é uma edição manual de texto. Abra o arquivo e decida o que deve permanecer: a sua versão, a da outra pessoa, ou uma combinação das duas. Em seguida, apague os três marcadores e todo o conteúdo que não for aproveitado, deixando o arquivo exatamente como deve ficar:

<h1>Livro de receitas da vovó</h1>

Os marcadores <<<<<<<, ======= e >>>>>>> não são código: são sinalização do Git. Esquecer de apagá-los é o erro mais comum, e o resultado aparece publicado na página, à vista de todos.

Finalizando

Depois de editar o arquivo, o conflito é encerrado como qualquer outra alteração, com add e commit:

git add receitas.html
git commit -m "Resolve conflito no título da página"
git push

A outra pessoa roda git pull e recebe a versão final, já resolvida.

Um conflito não significa que alguém errou. Ele é uma consequência normal de duas pessoas trabalharem ao mesmo tempo, e saber resolvê-lo com calma faz parte do trabalho.

Referência rápida

Referências

• “The Beginner’s Guide to Git & GitHub”. freeCodeCamp, 2019. freecodecamp.org
• Pro Git Book, gratuito e em português. git-scm.com/book/pt-br/v2
• GitHub Docs: Autenticação. docs.github.com