Git e GitHub do zero

Imagine escrever um trabalho e salvar versões: "trabalho_v1", "trabalho_final", "trabalho_final_mesmo". No começo funciona, mas vira caos rápido: você não sabe qual versão é qual, perde mudanças, não consegue voltar quando muda algo e tudo quebra.

Git resolve isso de forma elegante e organizada. É um jeito de anotar cada mudança do projeto de modo que você sempre saiba o que mudou, quando e por quê. Toda vez que você marca um ponto (chamado commit), fica gravado o que mudou. Se precisar voltar a uma versão anterior, está ali. Se quiser entender a história do projeto, lê os commits como um diário.

É por isso que toda empresa usa Git: funciona, é confiável e torna a colaboração possível.

Essa confusão é comum, então vale separar de verdade.

Git é a ferramenta que roda na sua máquina. Ela guarda o histórico do projeto localmente, na pasta dele. Você usa Git pelo terminal.

GitHub é um site onde você hospeda projetos versionados com Git. É onde o código fica acessível, onde outras pessoas colaboram, onde você mostra o que construiu.

Git é o caderno onde você registra tudo. GitHub é o lugar onde você coloca o caderno pra outras pessoas lerem.

Existem outros (GitLab, Bitbucket), mas GitHub é de longe o mais usado.

Não precisa decorar de primeira. A gente usa Git repetidamente e o vocabulário entra sozinho. Enquanto isso, estes conceitos são o essencial.

Repositório (repo): a pasta do seu projeto com o histórico do Git dentro. Na prática, é a pasta que você está versionando.

Commit: um ponto salvo no histórico. Cada commit tem uma mensagem dizendo "o que mudou neste ponto". Tipo um checkpoint num videogame.

Branch: uma linha de trabalho paralela. Serve para mexer em algo sem estragar a versão principal (normalmente main). Pensa como um universo paralelo do projeto.

Remoto: a cópia do repositório hospedada no GitHub (ou GitLab, etc.). O push envia seus commits pra lá; o pull traz o que está lá pra sua máquina.

Clone: baixar um repositório inteiro do GitHub para a sua máquina pela primeira vez.

Com isso você já entende as palavras que vai ouvir por aí.

A primeira vez que você versiona um projeto, você escolhe um entre dois caminhos:

Opção 1: começar do zero

git init                 # cria o repositório na pasta atual

Feito. Agora você tem um folder .git (oculto) que guarda todo o histórico.

Opção 2: clonar um projeto existente

git clone <url-do-repo>  # baixa tudo de uma vez

Escolha qual faz sentido pro seu caso. Depois disso, o dia a dia é o mesmo.

No dia a dia, o ciclo se repete:

git status               # vê o que mudou
git add .                # marca as mudanças pro próximo commit
git commit -m "mensagem clara do que mudou"
git push                 # envia os commits pro GitHub

Dica: git status é seu amigo. Rode quantas vezes precisar. Ele só mostra informação, não estraga nada.

Trabalhando em algo isolado (branch)

Se você quer mexer numa coisa nova sem mexer na main, você cria uma branch:

git checkout -b minha-feature   # cria e entra numa branch nova
# ...você faz as mudanças, dá add, commit...
git push -u origin minha-feature

Depois disso, no GitHub você abre um Pull Request pra juntar sua branch com a main. Mas isso é assunto de depois.

O GitHub é mais que um lugar pra guardar código. É onde você mostra o que você conseguiu construir. Recrutador, cliente e colega passam por lá pra entender o tipo de trabalho que você faz.

Algumas coisas que realmente fazem diferença:

Deixe seus projetos públicos (os que fizerem sentido mostrar). Código imperfeito que existe é muito melhor que código perfeito que só está na sua máquina.

Escreva um README em cada projeto explicando: o que ele faz, como rodar, o que você aprendeu. Um bom README mostra que você pensa em quem vai ler, e isso comunica mais que código sem contexto.

Caprice nas mensagens de commit. Elas contam a história do projeto e mostram que você pensa em organização. "corrige bug" é diferente de "corrige erro de cálculo no desconto do carrinho"; a segunda mostra que você entende o problema de verdade.

Use o perfil GitHub pra destacar seus melhores repositórios.

A qualidade de comunicação (como você explica o que fez) importa muito. Projectos bem documentados e com histórico limpo chamam mais atenção que quantidade de repositórios.

• Commits pequenos e frequentes. É muito mais fácil entender e desfazer um commit pequeno do que um gigante. E é mais seguro também.
• Mensagens descritivas. "ajustes" não diz nada a ninguém (nem a você mesmo em três meses). "corrige modal de login não fechar em mobile" diz tudo.
• Use um .gitignore pra não versionar o que não deve. Dependências (type node_modules), arquivos de ambiente, senhas, tokens. Isso nunca sobe no GitHub. Especialmente senhas.

[!ATENÇÃO] Nunca commita senhas, tokens ou chaves de API. Uma vez que entra no histórico do Git, é complicado tirar. Se isso acontecer, o time precisa revogar aquela chave.

• Sei a diferença entre Git (a ferramenta) e GitHub (o site)?
• Consigo criar um repositório, fazer commit e enviar pro GitHub?
• Tenho pelo menos um projeto meu no GitHub com um README que explica o que é?

Se respondeu sim pra esses três, você já está dentro do fluxo que a indústria toda usa. O resto é prática.

Próximo passo: versione o seu próximo projeto, por menor que seja. Não existe versão "pronta pra versionar". Existe apenas o momento em que você começa.