Git e Github

1. Introdução ao Controle de Versão

O controle de versão é um sistema que registra as alterações feitas em um arquivo ou conjunto de arquivos ao longo do tempo. Se algo quebrar, podemos voltar a uma versão anterior que funcionava. Se duas pessoas editarem o projeto ao mesmo tempo, o sistema ajuda a juntar as duas partes.

• Git: É a ferramenta (o motor) instalada no seu computador. Ele rastreia o histórico do código localmente.
• GitHub: É a plataforma na nuvem. Ele hospeda os repositórios Git, funciona como nosso backup central e oferece ferramentas para revisão de código e gestão de tarefas.

2. Primeiros Passos: Instalação e Autenticação

Instalação do Git

Baixe o instalador de acordo com o seu sistema operacional através do site oficial: 🔗 Download do Git SCM

Durante a instalação no Windows, você pode aceitar as configurações padrão (clicar em "Next" até o fim).

Configuração de Identidade

Logo após instalar, abra o terminal (ou Git Bash) e diga ao Git quem você é. Isso aparecerá em todo o histórico do projeto:

git config --global user.name "Seu Nome e Sobrenome"
git config --global user.email "seu-email@exemplo.com"

Autenticação no GitHub

O GitHub não aceita mais a sua senha de login no terminal por questões de segurança. Para enviar código, você precisa usar um Personal Access Token (PAT) ou uma Chave SSH.

Como criar um Token (PAT):

1. No GitHub, vá em Settings (Configurações do seu perfil) > Developer settings > Personal access tokens > Tokens (classic).
2. Clique em Generate new token , dê um nome, defina a validade e marque a caixa repo (para controle total de repositórios).
3. Gere o token e copie-o (ele não será exibido novamente). Use esse token quando o terminal pedir sua senha ao fazer um git push.

3. Git: Operações e Fluxos Locais

O Ciclo de Vida dos Arquivos

Entenda onde o seu código está antes de executar os comandos:

1. Untracked: Arquivo novo, o Git ainda não o conhece.
2. Modified: Arquivo existente que foi alterado, mas não está pronto para ser salvo.
3. Staged: Arquivo na área de preparação (pronto para ser empacotado).
4. Committed: Alteração salva de forma permanente no histórico local.

Comandos Essenciais de Rotina

• git init: Inicializa um repositório Git em uma pasta vazia.
• git status: Seu melhor amigo. Mostra o estado atual dos arquivos (modificados, preparados, etc).
• git add <arquivo>: Move um arquivo para a área de preparação (Staged). Use git add . para adicionar tudo de uma vez.
• git commit -m "mensagem": Tira a "foto" oficial dos arquivos que estavam em Staged e salva no histórico.

Histórico e Correções

• git log: Exibe a lista de commits já feitos, com seus autores e mensagens.
• git diff: Mostra exatamente as linhas que foram adicionadas (em verde) ou removidas (em vermelho) antes de fazer o commit.
• git restore <arquivo>: Descarta as alterações locais de um arquivo que ainda não sofreu commit.
• git reset <commit>: Volta o projeto para um commit anterior. Usar --soft mantém seus arquivos alterados; usar --hard apaga as alterações locais (use com cuidado).

4. Ramificações (Branches) e Organização de Código

Trabalhar na ramificação principal (main) o tempo todo é perigoso. Branches são universos paralelos onde você pode criar novas funcionalidades em segurança.

• git branch: Lista todas as branches locais.
• git switch <nome-da-branch> (ou git checkout): Muda para outra branch. Para criar uma nova e já mudar para ela, use git switch -c <nome-da-branch>.
• git merge <branch>: Pega o código de outra branch e junta com a branch em que você está no momento.
• git rebase <branch>: Alternativa ao merge que reescreve a história para deixá-la linear. Aviso: Nunca faça rebase em branches públicas que outras pessoas já estão usando.

5. Boas Práticas: Padronização de Commits

Evite mensagens como "ajustes", "consertei o erro" ou "atualizando". Vamos adotar o padrão Conventional Commits para manter o histórico profissional e fácil de ler.

A estrutura básica é: tipo(escopo): descrição curta

Tipos mais usados:

• feat: Nova funcionalidade (ex: feat(login): adiciona validacao de email).
• fix: Correção de bug (ex: fix(carrinho): corrige calculo do total).
• docs: Apenas mudanças na documentação (ex: docs: atualiza tutorial no README).
• refactor: Mudança no código que não corrige um bug nem adiciona um recurso, apenas melhora a estrutura.

6. GitHub: Sincronização e Colaboração

Como conectar o trabalho do seu computador com o repositório na nuvem.

• git remote add origin <link-do-repositorio>: Conecta sua pasta local ao repositório do GitHub.
• git push origin <nome-da-branch>: Envia os seus commits locais para o GitHub.
• git fetch: Atualiza a lista de informações do repositório remoto sem alterar o seu código local.
• git pull: Puxa as atualizações do GitHub e já as mescla no seu código local.

.gitignore - O que é?

Um arquivo de texto onde colocamos os nomes das pastas e arquivos que o Git nunca deve monitorar (como a pasta node_modules, arquivos .env com senhas ou compilados).

7. O Fluxo de Trabalho com Pull Requests (PRs)

Um Pull Request é o pedido formal para que o código da sua branch seja integrado à branch principal (main ou develop). Esse é o nosso fluxo oficial:

1. Crie uma branch para a sua tarefa: git switch -c feat/nova-tela.
2. Trabalhe, adicione (git add) e faça os commits locais.
3. Envie sua branch para o GitHub: git push origin feat/nova-tela.
4. No GitHub, clique no botão Compare & pull request.
5. Revisão (Code Review): Avise o time. Outro colega deve ler o seu código no GitHub, fazer comentários ou pedir alterações e, se estiver tudo certo, aprovar o PR e fazer o Merge.

8. Resolução de Conflitos (Merge Conflicts)

Conflitos acontecem quando duas pessoas editam a mesma linha do mesmo arquivo. O Git não sabe qual versão manter e pausa o merge para você decidir.

Quando isso ocorrer, você verá marcações assim no seu código:

<<<<<<< HEAD
<h1>Bem-vindo ao Sistema</h1>
=======
<h1>Sistema de Gerenciamento - Login</h1>
>>>>>>> feat/nova-tela

Como resolver:

1. Abra o arquivo no seu editor de código (o VS Code facilita muito isso exibindo botões clicáveis).
2. Leia as duas versões. Apague a marcação (<<<<<<<, =======, >>>>>>>) e deixe apenas a linha correta que deve ficar na versão final (pode ser a sua, a do colega, ou uma mistura das duas).
3. Salve o arquivo.
4. No terminal, avise ao Git que foi resolvido: git add <arquivo-resolvido>.
5. Conclua o processo com um commit: git commit -m "fix: resolve conflito de merge no titulo".

Se tiverem dúvidas podem perguntar que eu incremento nesse material.