Git e GitHub para iniciantes: os comandos e o fluxo que você vai usar todo dia

Atualizado em 11 de outubro de 2026 · Leitura de 7 min

Edson Feitosa de Oliveira Junior Fundador e Engenheiro Líder · PruPru Digital Services

Git é o programa que guarda o histórico do seu código no seu computador. GitHub é um site que hospeda esse histórico na internet para você fazer backup, mostrar seu trabalho e colaborar com outras pessoas. Você pode usar Git sem GitHub, mas o contrário não faz sentido: o GitHub existe em cima do Git.

A boa notícia é que, no dia a dia, um desenvolvedor usa uns dez comandos. Neste guia você vai entender os conceitos (repositório, commit, branch, merge, pull request), ver o fluxo completo com exemplos e aprender a resolver o primeiro conflito sem pânico.

Os conceitos em linguagem simples

• Repositório (repo): a pasta do projeto com uma subpasta oculta .git, onde fica todo o histórico.
• Commit: uma "foto" do projeto em um momento, com autor, data e uma mensagem explicando o que mudou.
• Staging (área de preparação): onde você escolhe quais alterações vão entrar no próximo commit. É o passo do git add.
• Branch: uma linha de desenvolvimento paralela. Você cria uma branch para cada funcionalidade ou correção e não mexe direto na principal.
• Merge: juntar o trabalho de uma branch em outra.
• Remoto: a cópia do repositório em outro lugar, normalmente no GitHub. Por convenção, o nome dele é origin.
• Pull request (PR): um pedido, feito no GitHub, para juntar sua branch à principal. É ali que acontece a revisão de código.

Instalação e configuração inicial

No Windows, baixe o instalador em git-scm.com e aceite as opções padrão (ele instala também o Git Bash). No Linux, use o gerenciador de pacotes da distribuição, por exemplo sudo apt install git no Ubuntu. No macOS, o Git vem com as Command Line Tools do Xcode. Depois, configure seu nome e e-mail, que aparecem em cada commit:

git config --global user.name "Seu Nome"
git config --global user.email "voce@exemplo.com"
git config --global init.defaultBranch main

Use no GitHub o mesmo e-mail configurado aqui, assim os commits aparecem vinculados ao seu perfil. Ative também a verificação em duas etapas na conta do GitHub; é uma conta que vale proteger, como explicamos no artigo sobre senhas e autenticação em dois fatores.

O fluxo básico: do primeiro commit ao GitHub

Imagine um projeto novo em uma pasta chamada minha-api. O caminho completo fica assim:

1. Entre na pasta e inicie o repositório: git init.
2. Veja o que mudou: git status. Use esse comando o tempo todo, ele diz exatamente em que situação você está.
3. Adicione os arquivos ao staging: git add . (tudo) ou git add caminho/arquivo (um arquivo).
4. Crie o commit: git commit -m "Cria endpoint de listagem de pedidos".
5. No GitHub, crie um repositório vazio (sem README, para não gerar conflito no primeiro envio).
6. Ligue o repositório local ao remoto e envie:

git remote add origin https://github.com/seu-usuario/minha-api.git
git push -u origin main

O -u só é necessário na primeira vez; depois basta git push. Para baixar o que outras pessoas enviaram, use git pull. Para trazer um projeto existente para a sua máquina, use git clone com a URL do repositório.

Ao enviar pela primeira vez por HTTPS, o GitHub não aceita a senha da conta. No Windows, o Git Credential Manager (instalado junto com o Git) abre o navegador para você autorizar. Outra opção é configurar uma chave SSH.

O arquivo .gitignore

Nem tudo deve ir para o repositório. Pastas geradas na compilação, dependências baixadas e, principalmente, arquivos com senhas e chaves de API ficam de fora. Crie um arquivo .gitignore na raiz do projeto, por exemplo:

target/
node_modules/
.env
*.log
.idea/

Atenção: se você já fez commit de uma senha, apagar o arquivo depois não resolve, porque ela continua no histórico. O correto é trocar a senha ou revogar a chave imediatamente e só então limpar o histórico.

Branches e merge no dia a dia

A regra prática é: a branch main deve estar sempre funcionando. Para cada tarefa, crie uma branch:

git switch -c feature/filtro-por-data
# trabalhe, faça um ou vários commits
git add .
git commit -m "Adiciona filtro por data na listagem de pedidos"
git push -u origin feature/filtro-por-data

O git switch existe desde o Git 2.23; em tutoriais antigos você verá git checkout -b, que faz a mesma coisa. Para voltar à principal, use git switch main. Para juntar a branch localmente:

git switch main
git pull
git merge feature/filtro-por-data

Em equipe, porém, o merge costuma acontecer pelo pull request, não pelo terminal.

Pull request: como funciona a revisão

Depois do git push da sua branch, o GitHub mostra um botão "Compare & pull request". No PR você descreve o que fez, por que fez e como testar. Os colegas comentam linha a linha, você corrige com novos commits na mesma branch e, quando aprovado, alguém clica em merge. Um bom PR é pequeno: é muito mais fácil revisar 150 linhas do que 2.000.

Mesmo estudando sozinho, vale abrir PRs no seu próprio repositório. Isso cria o hábito e deixa um histórico organizado, algo que conta pontos em um portfólio de desenvolvedor júnior.

Resolvendo o primeiro conflito

Conflito acontece quando duas branches alteram as mesmas linhas de um arquivo e o Git não sabe qual versão manter. Ele interrompe o merge e marca o trecho assim:

<<<<<<< HEAD
int limite = 50;
=======
int limite = 100;
>>>>>>> feature/filtro-por-data

1. Rode git status para ver quais arquivos estão em conflito.
2. Abra cada arquivo e decida o resultado final: uma versão, a outra ou uma combinação. Apague os marcadores <<<<<<<, ======= e >>>>>>>.
3. Compile e teste.
4. Marque como resolvido com git add arquivo e finalize com git commit.

Se se perder no meio do caminho, git merge --abort desfaz a tentativa e volta ao estado anterior. Editores como VS Code e IntelliJ mostram os conflitos lado a lado e facilitam bastante.

Mensagens de commit que ajudam

O histórico é lido meses depois, por você ou por outra pessoa tentando entender um bug. Algumas boas práticas:

• Escreva no imperativo e diga o que o commit faz: "Corrige cálculo de frete para CEP do interior", e não "ajustes" ou "teste".
• Primeira linha curta (até uns 50 a 70 caracteres). Se precisar explicar o porquê, deixe uma linha em branco e escreva o corpo.
• Um commit, um assunto. Misturar refatoração com correção de bug dificulta a revisão e a reversão.
• Muitas equipes usam o padrão Conventional Commits, com prefixos como feat:, fix: e docs:. Siga o padrão do projeto em que estiver.

Comandos para desfazer coisas

Evite git push --force em branches compartilhadas, principalmente na main: ele reescreve o histórico remoto e pode apagar o trabalho de colegas. E lembre que o GitHub não substitui uma política de backup de arquivos para o resto do seu computador.

Com Git dominado, os próximos passos naturais são aprender Docker e publicar sua primeira API com Spring Boot em um repositório bem organizado.

Perguntas frequentes