# Git e GitHub para iniciantes: commits, branches, pull requests e seu portfólio, com comandos testados > Git guarda a história do seu código no seu computador, e o GitHub hospeda esses repositórios na internet. Veja os comandos essenciais (que a Redação rodou, com as saídas reais, inclusive um conflito de merge), como escrever bons commits, o fluxo de branch e pull request, README, .gitignore e como montar um portfólio. - Editoria: Carreira - Autor: Redação PushTech - Publicado em: 2026-10-24T21:44:00-03:00 - URL canônica: https://pushtech.tech/carreira/git-e-github-para-iniciantes-commits-branches-pull-requests-e-seu-portfolio **Git guarda a história do seu código no seu computador, e o GitHub hospeda essa história na internet para você mostrar e compartilhar.** É o quinto artigo da trilha "Quero virar dev em casa", e ele resolve um problema que todo iniciante tem: a pasta cheia de `projeto-final`, `projeto-final2` e `projeto-final-agora-vai`. No fim, você terá a lista de tarefas do artigo anterior publicada em um repositório organizado, com README e um histórico limpo. Antes, veja [JavaScript para iniciantes](/carreira/javascript-para-iniciantes-dom-eventos-fetch-e-sua-primeira-lista-de-tarefas), que cria o projeto que vamos versionar. ## Para quem é este artigo Para quem já tem pelo menos um projeto no computador e quer guardá-lo, publicá-lo e mostrá-lo. **Pré-requisito:** um terminal (o Terminal do macOS, o do Linux ou o Git Bash no Windows) e uma conta no GitHub. Tempo de estudo sugerido: de 4 a 8 horas, entre leitura, vídeos e prática (estimativa da Redação). ## O que você vai aprender 1. A diferença entre Git e GitHub. 2. Instalar e configurar o Git. 3. Os comandos essenciais, com saídas reais. 4. Como escrever bons commits e ignorar arquivos. 5. Branches, merge e como resolver um conflito. 6. O fluxo de pull request e como montar o portfólio. ## Git e GitHub não são a mesma coisa Segundo o GitHub, **Git** é um sistema de controle de versão que rastreia mudanças em arquivos e roda no seu computador. O **GitHub** é uma plataforma construída sobre o Git: hospeda seus repositórios na nuvem e acrescenta ferramentas de colaboração, como as issues e os pull requests. Em resumo, o Git gerencia a história do código, e o GitHub a hospeda online. ## Como o Git pensa: instantâneos e três estados O livro *Pro Git* explica três ideias que tornam tudo mais simples: - **Instantâneos, não diferenças.** O Git "tira uma foto" de como todos os seus arquivos estão naquele momento e guarda uma referência a ela. - **Quase tudo é local.** Você tem a história inteira no seu disco, então a maioria das operações é quase instantânea. - **Integridade.** Tudo é verificado por um código de verificação (um hash SHA-1) antes de ser guardado. Cada arquivo está em um de três estados: **modificado** (você mudou, mas ainda não registrou), **preparado** (staged: marcado para entrar no próximo commit) e **confirmado** (committed: guardado com segurança no banco de dados local). Eles correspondem a três áreas: a **árvore de trabalho** (a pasta onde você edita), a **área de preparação** (a lista do que entrará no próximo commit) e o **diretório Git** (onde ficam a história e os metadados). ## Instalar e configurar 1. **Instale o Git**, baixando a versão mais recente em `git-scm.com`. 2. **Diga quem você é.** O Git usa seu nome e seu e-mail para identificar cada commit: ```bash git config --global user.name "Seu Nome" git config --global user.email "seu-email@exemplo.com" git config --global user.name ``` A última linha confere o nome configurado. O GitHub explica que o nome do commit é separado do seu nome de usuário e que commits antigos mantêm o nome original. **Privacidade (da Redação):** em repositórios públicos, trate o nome e o e-mail dos seus commits como informação pública. O GitHub oferece um endereço de e-mail "noreply" (sem resposta) para você usar no lugar do seu e-mail real: em **Settings > Emails**, ative **Keep my email addresses private**. Siga o guia oficial para ver o endereço exato. A página do GitHub não informa se o e-mail do commit é publicamente visível, então o jeito seguro é assumir que sim. 3. **Autenticação com o GitHub.** O GitHub recomenda autenticar por HTTPS, com um assistente que guarda suas credenciais, ou por SSH, e também permite usar o GitHub CLI (`gh auth login`). A Redação não testou essa etapa; siga os guias oficiais que a página "Set up Git" indica. ## Os comandos essenciais, com saídas reais A Redação rodou a sequência abaixo com o Git 2.54, em um repositório de teste. As saídas são as reais. ### Criar o repositório e fazer o primeiro commit ```bash git init -b main meu-curriculo cd meu-curriculo git status -s ``` Saída do `status`, com os arquivos do projeto ainda sem acompanhamento (untracked): ```text ?? tarefas.css ?? tarefas.html ?? tarefas.js ``` ```bash git add tarefas.html tarefas.css tarefas.js git status -s git commit -m "Adiciona lista de tarefas" git log --oneline ``` ```text A tarefas.css A tarefas.html A tarefas.js 9e61219 Adiciona lista de tarefas ``` O que aconteceu: `git add` coloca o conteúdo na **área de preparação** (o *Pro Git* resume como "adicione exatamente este conteúdo ao próximo commit", e não "adicione este arquivo ao projeto"), e `git commit` guarda o instantâneo. O `A` na primeira coluna do `status` indica que o arquivo foi preparado. O código `9e61219` é o início do hash do commit. Se você editar um arquivo depois de prepará-lo, precisa rodar `git add` de novo para preparar a versão mais recente. E `git diff` mostra o que mudou e ainda não foi preparado (`git diff --staged` mostra o que já foi preparado). ### README e .gitignore Crie um `README.md` (veja a seção sobre README, mais adiante) e um arquivo `.gitignore` com os padrões do que o Git não deve acompanhar: ```text .DS_Store node_modules/ ``` Regras do *Pro Git*: linhas em branco e linhas que começam com `#` são ignoradas; um `/` no fim indica um diretório; um `!` no começo nega um padrão. No teste, havia um arquivo `.DS_Store` na pasta e ele **não apareceu** no `git status`, como esperado. **Regra de ouro (da Redação):** nunca faça commit de senhas, chaves de API ou arquivos como `.env`. Coloque-os no `.gitignore` **antes** do primeiro commit: o que entra no histórico é difícil de apagar de verdade. ### Branches: trabalhar sem estragar o que funciona Uma **branch** é uma linha separada de trabalho. Segundo o GitHub, uma nova branch começa como cópia da `main`, e você experimenta sem mexer no código principal até decidir juntá-lo. O *Pro Git* usa `git checkout -b`; o `git switch -c` faz o mesmo nas versões novas do Git, e a Redação testou os dois. ```bash git checkout -b filtro-prioridade git commit -am "Estilo da prioridade" git checkout main git merge filtro-prioridade git branch -d filtro-prioridade ``` Saída do `merge`: ```text Updating 8904a6c..4f52550 Fast-forward tarefas.css | 1 + 1 file changed, 1 insertion(+) ``` O *Pro Git* explica o "avanço rápido" (fast-forward): se a `main` não teve commits novos desde que você criou a branch, o Git só move o ponteiro para frente. O `branch -d` apaga a branch já incorporada. Atenção: o `commit -a` prepara todos os arquivos já acompanhados e modificados, e o livro avisa que isso pode incluir mudanças que você não queria. ### Conflito de merge: o susto que não é um susto Um conflito acontece quando você mudou **o mesmo trecho do mesmo arquivo** de duas formas diferentes em branches diferentes. A Redação provocou um de propósito: mudou o título do `README.md` em duas branches. ```text Auto-merging README.md CONFLICT (content): Merge conflict in README.md Automatic merge failed; fix conflicts and then commit the result. ``` O `git status -s` mostrou `UU README.md` (os dois lados modificaram), e o arquivo ficou assim: ```text <<<<<<< HEAD # Lista de tarefas em JavaScript ======= # Minha lista de tarefas >>>>>>> titulo-novo ``` Como resolver, conforme o *Pro Git*: 1. **Edite o arquivo** deixando o conteúdo que você quer e **apagando as linhas** `<<<<<<<`, `=======` e `>>>>>>>`. 2. **`git add README.md`**, o que marca o conflito como resolvido. 3. **`git commit`** para concluir o merge. A história resultante é a da imagem desta matéria: duas linhas que se separam e se juntam em um commit de merge. **O conflito não é erro seu**: é o Git pedindo que um humano decida qual versão vale. ### Enviar para o GitHub Crie um repositório vazio no GitHub, copie o endereço dele e conecte: ```bash git remote add origin ENDERECO-DO-REPOSITORIO git push -u origin main ``` No teste, com um repositório remoto simulado em disco, a saída foi `* [new branch] main -> main` e `branch 'main' set up to track 'origin/main'`. Com o GitHub de verdade, você precisa estar autenticado (veja a seção de configuração). ## Como escrever bons commits (da Redação) - **Um assunto por commit.** Se a mensagem precisa de "e", talvez sejam dois commits. - **Mensagem no imperativo, curta e específica:** "Adiciona filtro de tarefas pendentes", e não "mudanças" nem "ajustes". - **Commit pequeno e frequente.** É mais fácil de entender e de desfazer. - **Não faça commit de código quebrado** na `main` quando puder evitá-lo; use uma branch. - **Releia o `git status` antes do commit.** Veja o que está prestes a entrar. Mensagens ruins: `final`, `arrumei`, `asdf`. Mensagens boas: `Corrige id repetido ao remover tarefa`, `Adiciona README com instruções`. ## O fluxo do GitHub: branch, commit e pull request Segundo o guia "Hello World" do GitHub, o fluxo pela interface web é: 1. **Crie um repositório**, com um README. 2. **Crie uma branch** (por exemplo, `readme-edits`) a partir da `main`. 3. **Faça e confirme mudanças** na nova branch, com uma mensagem descritiva. 4. **Abra um pull request**, uma proposta de juntar uma branch em outra, que mostra as diferenças para que outras pessoas revisem e discutam antes. 5. **Faça o merge** e, se quiser, apague a branch. Mesmo trabalhando sozinho, vale usar branch e pull request: você pratica o fluxo que as equipes usam e deixa um histórico legível. ## README e portfólio O GitHub diz que o README serve para "comunicar informações importantes sobre o seu projeto" e costuma ser o primeiro lugar que o visitante olha. Segundo a página, um bom README costuma dizer **o que o projeto faz, por que é útil, como começar, onde pedir ajuda e quem o mantém**. O GitHub o exibe automaticamente na página do repositório. **Modelo de README para a lista de tarefas (da Redação):** ```markdown # Lista de tarefas Pequeno app em JavaScript puro para adicionar, concluir, remover e filtrar tarefas. Os dados ficam salvos no navegador (localStorage). ## Demonstração https://seu-usuario.github.io/lista-de-tarefas/ ## Como usar Abra `tarefas.html` por um servidor local (por exemplo, `python3 -m http.server`). ## O que aprendi DOM, eventos e armazenamento no navegador. ``` **Um README de perfil:** o GitHub informa que um README em um repositório público com o **mesmo nome do seu usuário** aparece no seu perfil. É um bom cartão de visita. **Portfólio, na prática (da Redação):** - Destaque no seu perfil poucos projetos **terminados e explicados**, em vez de muitos pela metade. - Cada projeto: README, link para a demonstração (GitHub Pages, como no [artigo 3](/carreira/html-e-css-como-criar-e-publicar-sua-primeira-pagina-de-verdade)) e uma captura de tela ou GIF. - Mostre a **evolução**: commits claros e frequentes contam mais do que um projeto enorme com um commit só. ## Vídeos para estudar Os quatro vídeos foram verificados quanto ao título, ao canal, à duração, à data e à possibilidade de incorporação. A Redação não os assistiu na íntegra nem verificou o que dizem. _Vídeo: GIT: Minicurso para Você Sair do Zero! (Aprenda em 45 Minutos) (Código Fonte TV)_ _Vídeo: APRENDA GIT e GITHUB DO ZERO - guia completo (Fernanda Kipper)_ _Vídeo: Aprenda Git e Github em 5 minutos (Igor Mucharski)_ _Vídeo: Git and GitHub for Beginners - Crash Course (freeCodeCamp.org)_ ## Exercícios práticos 1. **Seu primeiro repositório:** crie uma pasta, rode `git init`, faça três commits com mensagens claras e confira com `git log --oneline`. 2. **Ignore algo:** crie um arquivo `.env` de mentira, coloque-o no `.gitignore` e confirme que ele não aparece no `git status`. 3. **Branch e merge:** crie uma branch, mude um arquivo, volte para a `main` e faça o merge. 4. **Provoque um conflito de propósito**, resolva e leia o histórico com `git log --oneline --graph`. 5. **Pull request solitário:** no GitHub, abra um pull request de uma branch sua para a `main` e faça o merge. 6. **Desfazer com calma:** descubra, na documentação, a diferença entre `git restore` e `git revert`, e teste uma vez em um repositório de treino. ## Mini-projeto: publique a lista de tarefas Publique a lista de tarefas do artigo anterior no GitHub com: - Repositório organizado (`tarefas.html`, `tarefas.css`, `tarefas.js`, `README.md`, `.gitignore`). - README com o que o projeto faz, como usar e uma captura de tela ou GIF. - Link para a demonstração no GitHub Pages. - Commits claros e progressivos (pelo menos cinco). **Resultado esperado:** um repositório que um recrutador consiga entender em dois minutos. ## Erros comuns de iniciantes - **Fazer commit de tudo de uma vez**, com mensagem "final". - **Esquecer o `git add`** e achar que o commit guardou a mudança. - **Fazer commit de senhas ou do `.env`.** - **Trabalhar direto na `main`** quando uma branch seria mais segura. - **Ter medo de conflito.** Ele é normal e se resolve em três passos. - **Usar `git commit -a` sem olhar** o que está sendo incluído. - **Não escrever README.** Sem ele, ninguém entende seu projeto. - **Copiar comando sem entender.** Rode `git status` com frequência: ele diz onde você está. ## Checklist de conclusão - [ ] Configurei meu nome e meu e-mail no Git, e escolhi o que fazer com a privacidade do e-mail. - [ ] Fiz commits com mensagens claras em um repositório meu. - [ ] Usei `.gitignore` e nunca fiz commit de segredos. - [ ] Criei uma branch, fiz merge e resolvi um conflito de treino. - [ ] Abri um pull request e fiz o merge no GitHub. - [ ] Escrevi um README para a lista de tarefas. - [ ] Publiquei o projeto e o link da demonstração funciona. ## Próximo passo da trilha Com o Git na mão, o próximo artigo ajuda você a **sair dos tutoriais e criar um projeto seu**, do começo ao fim, com o seu repositório como vitrine. ## Perguntas frequentes ### Qual a diferença entre Git e GitHub? Segundo o GitHub, o Git é um sistema de controle de versão que roda no seu computador e rastreia mudanças. O GitHub é uma plataforma que hospeda repositórios Git na nuvem e acrescenta ferramentas de colaboração, como pull requests. ### O que é um commit? Segundo o GitHub, é um conjunto salvo de mudanças, com uma mensagem que explica o que mudou e por quê. ### O que é uma branch? É uma versão separada do repositório. Segundo o GitHub, uma nova branch começa como cópia da `main`, e você experimenta sem alterar o código principal até fazer o merge. ### O que é um pull request? Segundo o GitHub, é uma proposta de juntar uma branch em outra, que mostra as diferenças para que outras pessoas revisem e discutam antes. ### O que é um conflito de merge e como resolver? Acontece quando o mesmo trecho do mesmo arquivo foi mudado de formas diferentes em duas branches. Segundo o *Pro Git*, você edita o arquivo removendo os marcadores, roda `git add` no arquivo e conclui com `git commit`. ### Preciso saber Git para conseguir emprego? A Redação não encontrou fonte oficial que dê um número de vagas que exigem Git, e por isso não o cita. Em geral, saber usar controle de versão é considerado uma habilidade básica de quem programa, e um repositório bem organizado ajuda a mostrar seu trabalho. Esta é uma observação da Redação. ### Como evitar subir senhas para o GitHub? Coloque arquivos como `.env` no `.gitignore` antes do primeiro commit e nunca escreva chaves direto no código. Esta é uma recomendação da Redação. ### O e-mail dos meus commits fica público? A página do GitHub não informa isso. Em repositórios públicos, assuma que sim e considere usar o endereço de e-mail "noreply" que o GitHub oferece em Settings > Emails. ## Fontes - [Pro Git: What is Git?](https://git-scm.com/book/en/v2/Getting-Started-What-is-Git%3F), Git (git-scm.com) - [Pro Git: Recording Changes to the Repository](https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository), Git (git-scm.com) - [Pro Git: Basic Branching and Merging](https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging), Git (git-scm.com) - [About GitHub and Git](https://docs.github.com/en/get-started/start-your-journey/about-github-and-git), GitHub Docs - [Hello World](https://docs.github.com/en/get-started/start-your-journey/hello-world), GitHub Docs - [About READMEs](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-readmes), GitHub Docs - [Setting your username in Git](https://docs.github.com/en/get-started/git-basics/setting-your-username-in-git), GitHub Docs - [Setting your commit email address](https://docs.github.com/en/account-and-profile/how-tos/email-preferences/setting-your-commit-email-address), GitHub Docs - [Set up Git](https://docs.github.com/en/get-started/git-basics/set-up-git), GitHub Docs