Carregando conteúdo…
Programação
Você está começando a programar e ainda não sabe o que são Git e GitHub? Veja a diferença e pratique os primeiros comandos no terminal.
Áudio
10 minutos, aproximadamente
Você está começando a programar e alguém pediu para “subir o projeto no GitHub”. A frase parece simples, mas reúne duas ferramentas diferentes. Git registra as mudanças nos arquivos do seu projeto. GitHub é um serviço que pode guardar uma cópia desse repositório na internet e ajudar outras pessoas a colaborar nele. Você pode usar Git sem criar uma conta no GitHub.
Neste guia, vamos criar um projeto pequeno, salvar duas versões e enviar o resultado ao GitHub. Os blocos de terminal trazem apenas comandos; digite um de cada vez. Você não precisa decorar tudo. O objetivo é entender o caminho que uma alteração percorre, do arquivo no computador até aparecer no site.
Imagine que você está escrevendo um jogo. Hoje ele funciona, amanhã você muda uma regra e, sem querer, quebra o placar. Se você salvou uma versão anterior com Git, consegue descobrir o que mudou e recuperar o trabalho. Cada versão registrada é um commit: uma fotografia do estado dos arquivos escolhidos naquele momento.
O Git funciona no seu computador e mantém o histórico dentro de uma pasta oculta chamada .git. O GitHub hospeda repositórios Git e acrescenta páginas para visualizar código, discutir mudanças, abrir issues e revisar pull requests. Outras plataformas também hospedam repositórios Git; o GitHub é uma delas.
| Termo | Em palavras simples |
|---|---|
| Repositório | Pasta do projeto acompanhada pelo Git, com seu histórico de alterações |
| Commit | Registro de uma versão dos arquivos selecionados, com uma mensagem que explica a mudança |
| Branch | Linha de trabalho separada, usada para desenvolver uma ideia sem mexer imediatamente na linha principal |
| Remoto | Endereço de outro repositório, como a cópia hospedada no GitHub |
| Pull request | Proposta para revisar e juntar mudanças de uma branch em outra no GitHub |
O ponto mais importante é este: salvar um arquivo, fazer um commit e enviar esse commit ao GitHub são três ações distintas. O commit é local. Ele só aparece no repositório remoto depois de um git push.
Instale o Git pelo site oficial e abra o terminal do sistema, o Git Bash ou o terminal integrado do editor. Confirme a instalação:
git --versionO comando deve mostrar um número de versão. Depois, configure o nome e o e-mail que serão associados aos seus commits. Substitua os exemplos pelos seus dados; use um e-mail vinculado à sua conta do GitHub se quiser que a plataforma associe os commits ao seu perfil.
git config --global user.name "Seu Nome"
git config --global user.email "seu-email@example.com"--global aplica essa identidade aos repositórios do seu usuário nesse computador. Você pode conferi-la com git config --global user.name e git config --global user.email. Esses comandos não fazem login no GitHub. Eles apenas identificam a autoria dos commits.
Crie uma pasta vazia para praticar e entre nela. O exemplo funciona no PowerShell, no Git Bash e em terminais comuns de macOS e Linux:
mkdir meu-primeiro-projeto
cd meu-primeiro-projeto
git init -b maingit init -b main cria o repositório local e chama a primeira branch de main. Ele não cria nada no GitHub. Abra a pasta no seu editor, crie um arquivo README.md com o texto abaixo e salve-o:
# Meu primeiro projeto
Estou aprendendo Git e GitHub.O README.md é a apresentação do projeto; no GitHub, ele costuma aparecer na página inicial do repositório. Agora pergunte ao Git o que aconteceu:
git statusO arquivo aparecerá como untracked ou “não rastreado”. Isso significa que ele existe na pasta, mas ainda não foi incluído em um commit. git status é um bom primeiro comando sempre que você não souber em que situação está o projeto.
O Git possui uma área de preparação, chamada staging area. git add coloca nela a versão atual dos arquivos que você quer registrar. Para este exercício, escolha apenas o README:
git add README.md
git status
git diff --cachedDepois do git add, o git status deve mostrar README.md entre as mudanças prontas para o próximo commit. git diff --cached mostra o conteúdo preparado. É uma última conferência antes de gravar a versão.
Se você editar o README depois de executar
git add, prepare-o novamente. O Git registra no commit a versão que estava na área de preparação, não necessariamente a versão mais recente que ficou aberta no editor.
Registre a primeira versão:
git commit -m "Adiciona apresentação do projeto"
git log --onelinegit commit -m cria o registro local, e a mensagem entre aspas explica o que foi feito. git log --oneline mostra um resumo do histórico. Se o Git reclamar que falta nome ou e-mail, volte à configuração anterior; uma conta no GitHub não substitui essa etapa.
No editor, acrescente uma linha ao final de README.md e salve:
Este repositório será usado para praticar comandos básicos.Antes de preparar a mudança, veja a diferença entre o arquivo atual e o último commit:
git diff
git add README.md
git diff --cached
git commit -m "Explica o objetivo do repositório"
git log --onelineAgora você deve ver dois commits. O primeiro preserva a apresentação inicial; o segundo registra o texto novo. Observe que git diff mostra mudanças ainda não preparadas, enquanto git diff --cached mostra o que entrará no próximo commit.
Entre no GitHub e crie um repositório chamado meu-primeiro-projeto. Para conectar este projeto local já iniciado, deixe desmarcadas as opções de criar README, .gitignore e licença no site. Assim, o repositório remoto começa vazio e evita um conflito desnecessário com os commits que acabamos de fazer. Escolha se ele será público ou privado e copie a URL HTTPS mostrada na tela.
No terminal, ainda dentro da pasta do projeto, substitua SEU-USUARIO pelo seu nome de usuário no GitHub:
git remote add origin https://github.com/SEU-USUARIO/meu-primeiro-projeto.git
git remote -v
git push -u origin mainorigin é apenas o nome usual dado ao endereço remoto. git remote -v permite verificar se a URL está certa. git push -u origin main envia os commits da branch main e estabelece uma associação com a branch remota. Depois disso, em geral basta git push para enviar novos commits feitos nessa branch.
O GitHub poderá abrir uma janela de autenticação no navegador. Para conexões HTTPS, a documentação do GitHub recomenda Git Credential Manager ou GitHub CLI; a senha da conta não é digitada como senha comum no git push. Se preferir, é possível configurar chaves SSH mais tarde. Depois que o envio terminar, atualize a página do repositório para ver o README e os dois commits.
O caminho anterior começou em uma pasta local. Se o repositório já existe no GitHub e você quer baixá-lo para outro computador, use clone, em uma pasta onde ainda não exista um diretório com o mesmo nome:
git clone https://github.com/SEU-USUARIO/meu-primeiro-projeto.git
cd meu-primeiro-projeto
git statusgit clone baixa os arquivos e o histórico e já configura o remoto origin. Não é necessário executar git init ou git remote add origin nesse projeto clonado. Se outra pessoa enviar commits ao repositório enquanto você trabalha, git pull traz e integra as atualizações da branch atual. Em projetos de equipe, confira o estado dos arquivos antes de integrar mudanças.
Depois de entender commits e push, você pode experimentar sem alterar imediatamente a main. A partir dela, crie uma branch para melhorar o README:
git switch -c melhora-readme
git statusEdite o README, salve e registre a mudança nessa branch:
git add README.md
git commit -m "Melhora as instruções do README"
git push -u origin melhora-readmeNo GitHub, abra um pull request de melhora-readme para main. Ele mostra o que mudou e permite revisar e discutir antes de juntar as duas linhas de trabalho. Enviar uma branch ao GitHub não altera automaticamente a main; a mudança entra nela depois do merge do pull request. Se você estiver apenas praticando, pode abrir o pedido e observar a comparação sem fazer o merge.
Antes de preparar arquivos, use git status e confira os nomes. git add . pode ser útil, mas inclui todas as alterações elegíveis da pasta; no começo, adicionar arquivos específicos ajuda a evitar surpresas. Não coloque senhas, tokens, chaves de API ou arquivos .env no repositório. Um repositório privado também não é um local adequado para guardar segredos.
Em projetos que geram dependências ou arquivos locais, crie um .gitignore antes do primeiro commit. Por exemplo, em um projeto Node.js:
node_modules/
.env
.env.*
!.env.exampleO .gitignore impede que arquivos ainda não rastreados sejam adicionados por padrão. Ele não apaga um segredo que já foi enviado ao histórico; nesse caso, é preciso revogar ou trocar a credencial. A documentação do GitHub sobre arquivos ignorados explica também como parar de rastrear um arquivo que já havia sido incluído.
Por fim, Git não publica um site sozinho. O GitHub guarda e apresenta o repositório, mas colocar uma aplicação no ar exige uma etapa própria de hospedagem ou deploy. Para praticar hoje, basta repetir o ciclo editar → conferir com git status e git diff → preparar com git add → registrar com git commit → enviar com git push. Quando cada passo fizer sentido, branches e colaboração ficam muito menos misteriosos.