Git, sem complicação

Git é um sistema de controle de versão distribuído (DVCS). É um programa que roda na sua máquina, sem depender de internet ou de conta em nenhum serviço, e guarda o histórico do projeto em forma de instantâneos (snapshots) das mudanças. Com o Git você cria branches, compara versões, desfaz alterações e reconstrói qualquer ponto do histórico do projeto — tudo isso localmente.

GitHub é uma plataforma na nuvem que hospeda repositórios Git e acrescenta uma camada de colaboração em torno deles: interface web, pull requests, revisão de código, issues, wikis, integração contínua (Actions) e páginas estáticas (Pages), entre outros recursos. GitHub não substitui o Git — ele depende do Git para existir, e é apenas uma, entre várias, empresas que oferecem esse tipo de serviço.

Na prática: Git é a ferramenta; GitHub é um serviço construído sobre ela. Um projeto pode ser versionado inteiramente com Git sem nunca subir para o GitHub — mas hospedar o repositório em algum serviço remoto facilita o backup, a colaboração e a publicação do código.

GitHub é o mais popular, mas não é o único serviço de hospedagem de repositórios Git. Outras opções conhecidas:

• GitHub — o mais usado no mercado; pertence à Microsoft; forte em código aberto e na comunidade de desenvolvedores.
• GitLab — pode ser usado na nuvem (gitlab.com) ou instalado em servidor próprio (self-hosted); inclui CI/CD integrado.
• Bitbucket — da Atlassian; integra-se bem com Jira e Trello, comum em times que já usam essas ferramentas.
• Codeberg — plataforma sem fins lucrativos, mantida pela comunidade, focada em software livre.

Criando uma conta no GitHub

1. Acesse github.com e clique em Sign up.
2. Informe um e-mail válido, crie uma senha forte e escolha um nome de usuário — ele fará parte do endereço dos seus repositórios.
3. Confirme a verificação exibida na tela e o código enviado para o seu e-mail.
4. Escolha o plano gratuito (Free); ele já atende à grande maioria dos projetos pessoais e acadêmicos.
5. Ative a autenticação em duas etapas (2FA) nas configurações de segurança da conta — recomendado por padrão.
6. Para enviar código pela linha de comando, crie um personal access token ou uma chave SSH: o GitHub não aceita mais senha comum em operações via HTTPS.

Depois de instalar o Git, antes do primeiro commit, é preciso dizer ao Git quem você é. Esses três comandos cobrem o básico:

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

Os dois últimos definem a autoria: nome e e-mail passam a ser gravados em cada commit que você fizer. O primeiro define o nome da branch padrão criada por git init.

Por que main em vez de master? Por anos, "master" foi o nome padrão da branch principal em praticamente todo repositório Git. A partir de 2020, o próprio Git passou a permitir configurar esse nome (init.defaultBranch), e serviços como GitHub, GitLab e Bitbucket adotaram main como padrão em novos repositórios — parte de um movimento da indústria para abandonar terminologia associada a "master/slave" e adotar um vocabulário mais neutro. Repositórios antigos continuam funcionando normalmente com "master"; a mudança afeta apenas o nome padrão de projetos novos, e pode ser configurada como preferir.

Níveis de configuração

O Git guarda configurações em arquivos diferentes, organizados em níveis. Do mais amplo ao mais específico:

• --system — vale para todas as pessoas usuárias da máquina; fica em um arquivo de configuração do próprio sistema operacional. Raramente usado no dia a dia.
• --global — vale para todos os repositórios do seu usuário; fica em ~/.gitconfig. É onde normalmente configuramos nome, e-mail e outras preferências pessoais, como nos comandos acima.
• --local — vale apenas para o repositório atual; fica em .git/config, dentro da pasta do projeto. É o padrão quando nenhuma flag é informada, e sobrescreve o valor global — útil, por exemplo, para usar um e-mail diferente em um repositório de trabalho.

Em caso de conflito, o mais específico vence: local > global > system. Para ver de onde vem cada configuração ativa, use git config --list --show-origin.

git init transforma a pasta atual em um repositório Git, criando uma subpasta oculta .git com toda a estrutura de controle de versão. A partir daí, o Git passa a observar as mudanças feitas ali dentro.

git init

Também é possível indicar uma pasta de destino. Se ela não existir, o Git a cria antes de inicializar o repositório — sem que você precise entrar nela primeiro:

git init minha-pasta
git init /caminho/completo/minha-pasta

Se init.defaultBranch não tiver sido configurado (passo anterior), o Git pode avisar que está usando um nome padrão provisório para a branch. Você pode renomeá-la a qualquer momento com git branch -m main.

Do zero ou a partir de uma cópia

Existem duas formas de começar a trabalhar com um repositório. Um projeto novo, que ainda não existe em lugar nenhum, começa com git init, como visto acima. Já um projeto que já existe em algum lugar — no GitHub, por exemplo — não precisa ser iniciado do zero: basta clonar o repositório existente para obter uma cópia completa dele, já inicializada e com todo o histórico de commits:

git clone URL_DO_REPOSITORIO

O Git cria uma pasta nova com o nome do repositório, baixa todos os arquivos, branches e o histórico de commits, e já configura o repositório remoto original (chamado origin) para os próximos git push e git pull.

Resumindo: use git init para começar um projeto do zero; use git clone para partir de um projeto que já existe.

Com o repositório iniciado, o ciclo básico de trabalho se repete a cada mudança feita no projeto:

git status
git add index.html
git commit -m "feat: cria a página inicial"
git log

git status

git status mostra em qual branch você está e a situação de cada arquivo desde o último commit. Os principais estados são:

• Untracked — arquivo novo, que o Git ainda não está rastreando; não existia (ou não era monitorado) no commit anterior.
• Modified — arquivo já rastreado, com alterações desde o último commit, ainda não preparadas para o próximo.
• Staged — arquivo já preparado com git add, pronto para entrar no próximo commit.
• Deleted — arquivo rastreado que foi removido da pasta de trabalho.
• Renamed — arquivo rastreado cujo nome ou caminho mudou; o Git costuma detectar a renomeação automaticamente quando o conteúdo permanece parecido.

Quando não há nada a mostrar, o Git exibe nothing to commit, working tree clean — sinal de que a pasta de trabalho está idêntica ao último commit. É o comando mais usado no dia a dia — vale rodar antes e depois de quase qualquer outro comando, para saber exatamente o que vai acontecer.

git add

git add prepara (coloca na área de staging) os arquivos que entrarão no próximo commit. Pode apontar um arquivo específico ou todos de uma vez:

git add index.html
git add .

git add . adiciona todos os arquivos novos e modificados a partir da pasta atual — exceto os que estiverem listados no .gitignore. O .gitignore é um arquivo de texto, na raiz do projeto, com um padrão por linha (nomes de arquivos, pastas ou extensões) que o Git deve ignorar: pastas como node_modules/, arquivos de configuração local, logs e segredos como .env não devem ser versionados e não aparecem quando você usa git add ..

git commit

git commit -m "mensagem" registra no histórico as mudanças que foram preparadas com git add. O commit exige que a identidade do autor já esteja configurada — nome e e-mail, como visto na seção de configuração — pois esses dados são gravados junto de cada commit; sem eles, o Git recusa o comando.

Uma convenção comum para escrever mensagens de commit é o Conventional Commits, que prefixa a mensagem com um tipo, indicando a natureza da mudança:

• feat — uma nova funcionalidade.
• fix — uma correção de bug.
• docs — mudanças apenas em documentação.
• style — formatação, espaçamento, ponto e vírgula — sem alterar o comportamento do código.
• refactor — reorganização do código que não corrige bug nem adiciona funcionalidade.
• test — inclusão ou ajuste de testes.

Exemplo: git commit -m "fix: corrige contraste do botão de menu". Não é uma regra do próprio Git, mas uma convenção amplamente adotada que facilita a leitura do histórico e pode ser usada para gerar changelogs automaticamente.

git log

git log exibe o histórico de commits do repositório, do mais recente para o mais antigo — hash, autor, data e mensagem de cada um. É como consultar a linha do tempo do projeto.

git log
git log --oneline
git log --oneline --graph --all

--oneline resume cada commit a uma linha (hash curto + mensagem), útil para uma visão rápida. --graph desenha a árvore de branches e merges, e --all inclui branches além da atual — uma combinação bastante usada para entender como o histórico se ramificou.

1. Criando um repositório remoto no GitHub

1. Com a conta já criada (seção 2), acesse github.com/new ou clique no + no canto superior direito e depois em New repository.
2. Escolha um nome para o repositório e, se quiser, uma descrição.
3. Deixe a visibilidade como Public — assim qualquer pessoa pode ver o projeto (é possível trocar para Private depois, se preferir).
4. Não marque as opções de criar README, .gitignore ou licença automaticamente se o repositório local já existe: elas criam arquivos que entram em conflito com o histórico que você já tem.
5. Clique em Create repository.

Na página seguinte, copie o endereço do repositório — o GitHub mostra tanto a versão HTTPS quanto a SSH. É esse endereço que conecta o repositório local ao remoto no próximo passo.

2. Configurando o remoto no repositório local

De volta ao terminal, dentro da pasta do projeto, registre o endereço copiado como remoto — por convenção, o nome origin é usado para o repositório remoto principal:

git remote add origin URL_DO_REPOSITORIO

Para conferir se o remoto foi configurado corretamente, use git remote -v: o comando lista os remotos conhecidos pelo repositório, com os endereços de leitura (fetch) e escrita (push).

3. Enviando o repositório local para o remoto

git push envia os commits do repositório local para o repositório remoto. No primeiro envio, use -u (de upstream) para associar a branch local à branch remota — nas próximas vezes, basta git push:

git push -u origin main

A partir daí, o GitHub passa a ter uma cópia completa do repositório, com todo o histórico de commits — pronta para ser acessada, clonada ou compartilhada com outras pessoas.

Depois do git push, o código já está no GitHub — mas ainda não está no ar, acessível por uma URL. Para páginas .html ou aplicações em JavaScript que rodam inteiramente no navegador, o GitHub oferece uma forma gratuita de publicar o repositório na internet: o GitHub Pages.

Publicando com GitHub Pages

1. No repositório, no GitHub, acesse a aba Settings (Configurações).
2. No menu lateral, clique em Pages (Páginas).
3. Em Build and deployment (Build e implantação), escolha a fonte (Source / Fonte): Deploy from a branch (Implantar a partir de um branch).
4. Selecione a branch a ser publicada (geralmente main) e a pasta — a raiz (/root) ou uma subpasta /docs.
5. Clique em Save (Salvar).

Depois de alguns instantes, o GitHub publica os arquivos e disponibiliza um endereço no formato https://seu-usuario.github.io/nome-do-repositorio/. Qualquer novo git push na branch configurada atualiza automaticamente o site publicado.

Atenção: o GitHub Pages hospeda apenas arquivos estáticos — HTML, CSS, JavaScript, imagens. Não existe servidor de back-end: não é possível rodar Node.js, PHP, Python, banco de dados ou qualquer código que precise ser executado no servidor. Tudo o que roda ali é front-end, processado inteiramente no navegador de quem acessa a página.