{
"$type": "site.standard.document",
"bskyPostRef": {
"cid": "bafyreihnbt6n6p63p4uayh5n3rtiqhrpfszhosy3l5mfnjzums3eci622m",
"uri": "at://did:plc:25rdn5elo5izoxrmtis34zuk/app.bsky.feed.post/3moojefvjqst2"
},
"coverImage": {
"$type": "blob",
"ref": {
"$link": "bafkreigrb4xpuf4mcx5jspxsrm3fxkr2jymrqimq2gjrouruixng3x6zdu"
},
"mimeType": "image/webp",
"size": 36318
},
"path": "/joaopedrov0/git-e-github-2iam",
"publishedAt": "2026-06-19T22:40:07.000Z",
"site": "https://dev.to",
"tags": [
"softwaredeveloment",
"software",
"git",
"github",
"Download do Git SCM"
],
"textContent": "## 1. Introdução ao Controle de Versão\n\nO 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.\n\n * **Git:** É a ferramenta (o motor) instalada no seu computador. Ele rastreia o histórico do código localmente.\n * **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.\n\n\n\n## 2. Primeiros Passos: Instalação e Autenticação\n\n### Instalação do Git\n\nBaixe o instalador de acordo com o seu sistema operacional através do site oficial:\n🔗 Download do Git SCM\n\nDurante a instalação no Windows, você pode aceitar as configurações padrão (clicar em \"Next\" até o fim).\n\n### Configuração de Identidade\n\nLogo após instalar, abra o terminal (ou Git Bash) e diga ao Git quem você é. Isso aparecerá em todo o histórico do projeto:\n\n\n\n git config --global user.name \"Seu Nome e Sobrenome\"\n git config --global user.email \"seu-email@exemplo.com\"\n\n\n\n### Autenticação no GitHub\n\nO 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**.\n\n**Como criar um Token (PAT):**\n\n 1. No GitHub, vá em _Settings_ (Configurações do seu perfil) > _Developer settings_ > _Personal access tokens_ > _Tokens (classic)_.\n 2. Clique em _Generate new token_ , dê um nome, defina a validade e marque a caixa **`repo`** (para controle total de repositórios).\n 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`.\n\n\n\n## 3. Git: Operações e Fluxos Locais\n\n### O Ciclo de Vida dos Arquivos\n\nEntenda onde o seu código está antes de executar os comandos:\n\n 1. **Untracked:** Arquivo novo, o Git ainda não o conhece.\n 2. **Modified:** Arquivo existente que foi alterado, mas não está pronto para ser salvo.\n 3. **Staged:** Arquivo na área de preparação (pronto para ser empacotado).\n 4. **Committed:** Alteração salva de forma permanente no histórico local.\n\n\n\n### Comandos Essenciais de Rotina\n\n * `git init`: Inicializa um repositório Git em uma pasta vazia.\n * `git status`: **Seu melhor amigo.** Mostra o estado atual dos arquivos (modificados, preparados, etc).\n * `git add <arquivo>`: Move um arquivo para a área de preparação (_Staged_). Use `git add .` para adicionar tudo de uma vez.\n * `git commit -m \"mensagem\"`: Tira a \"foto\" oficial dos arquivos que estavam em _Staged_ e salva no histórico.\n\n\n\n### Histórico e Correções\n\n * `git log`: Exibe a lista de commits já feitos, com seus autores e mensagens.\n * `git diff`: Mostra exatamente as linhas que foram adicionadas (em verde) ou removidas (em vermelho) antes de fazer o commit.\n * `git restore <arquivo>`: Descarta as alterações locais de um arquivo que ainda não sofreu commit.\n * `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).\n\n\n\n## 4. Ramificações (Branches) e Organização de Código\n\nTrabalhar na ramificação principal (`main`) o tempo todo é perigoso. Branches são universos paralelos onde você pode criar novas funcionalidades em segurança.\n\n * `git branch`: Lista todas as branches locais.\n * `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>`.\n * `git merge <branch>`: Pega o código de outra branch e junta com a branch em que você está no momento.\n * `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.\n\n\n\n## 5. Boas Práticas: Padronização de Commits\n\nEvite 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.\n\nA estrutura básica é: `tipo(escopo): descrição curta`\n\n**Tipos mais usados:**\n\n * **`feat:`** Nova funcionalidade (ex: `feat(login): adiciona validacao de email`).\n * **`fix:`** Correção de bug (ex: `fix(carrinho): corrige calculo do total`).\n * **`docs:`** Apenas mudanças na documentação (ex: `docs: atualiza tutorial no README`).\n * **`refactor:`** Mudança no código que não corrige um bug nem adiciona um recurso, apenas melhora a estrutura.\n\n\n\n## 6. GitHub: Sincronização e Colaboração\n\nComo conectar o trabalho do seu computador com o repositório na nuvem.\n\n * `git remote add origin <link-do-repositorio>`: Conecta sua pasta local ao repositório do GitHub.\n * `git push origin <nome-da-branch>`: Envia os seus commits locais para o GitHub.\n * `git fetch`: Atualiza a lista de informações do repositório remoto sem alterar o seu código local.\n * `git pull`: Puxa as atualizações do GitHub e já as mescla no seu código local.\n\n\n\n### `.gitignore` - O que é?\n\nUm 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).\n\n## 7. O Fluxo de Trabalho com Pull Requests (PRs)\n\nUm **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:\n\n 1. Crie uma branch para a sua tarefa: `git switch -c feat/nova-tela`.\n 2. Trabalhe, adicione (`git add`) e faça os commits locais.\n 3. Envie sua branch para o GitHub: `git push origin feat/nova-tela`.\n 4. No GitHub, clique no botão **Compare & pull request**.\n 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_.\n\n\n\n## 8. Resolução de Conflitos (Merge Conflicts)\n\nConflitos 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.\n\nQuando isso ocorrer, você verá marcações assim no seu código:\n\n\n\n <<<<<<< HEAD\n <h1>Bem-vindo ao Sistema</h1>\n =======\n <h1>Sistema de Gerenciamento - Login</h1>\n >>>>>>> feat/nova-tela\n\n\n\n**Como resolver:**\n\n 1. Abra o arquivo no seu editor de código (o VS Code facilita muito isso exibindo botões clicáveis).\n 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).\n 3. Salve o arquivo.\n 4. No terminal, avise ao Git que foi resolvido: `git add <arquivo-resolvido>`.\n 5. Conclua o processo com um commit: `git commit -m \"fix: resolve conflito de merge no titulo\"`.\n\n\n\nSe tiverem dúvidas podem perguntar que eu incremento nesse material.",
"title": "Git e Github"
}