Git e GitHub

Nesta Aula, as Fases são Entender → Preparar → Salvar → Rotina. Cada Fase reúne Etapas; dentro delas, os Passos dizem o que fazer. Pedido é o texto para colar no chat do Claude Code, com a pasta do projeto aberta. Comando é a linha para executar no terminal, a janela em que você dá instruções ao computador por texto.

Use primeiro o caminho Pelo Claude Code. A alternativa Pelo terminal permite realizar a mesma tarefa manualmente. Na Etapa 06, você também pode criar o repositório pelo site do GitHub. Escolha um caminho por tarefa para não repetir a criação.

Os Pedidos descrevem o resultado desejado. O Claude Code pode solicitar autorização para editar arquivos ou executar Comandos, conforme o modo de permissão da sessão. Leia a ação proposta e confira a pasta e o destino. Uma resposta dizendo que pretende fazer algo ainda não comprova que fez: confira o resultado de cada Passo.

Imagine uma proposta comercial que passou por várias revisões. Você quer saber o que mudou, quem mudou e qual versão foi aprovada. Renomear arquivos como “final”, “final-agora” e “final-valendo” logo fica confuso. O Git organiza esse histórico do projeto. A analogia é com um arquivo de versões identificadas: você decide quando registrar um novo marco.

Para seguir: você entende que o commit registra no computador e o push envia ao GitHub. Agora vamos preparar os dois lados.

Abra no Claude Code a pasta do projeto em que você trabalhou na Aula 04 — Instalação no macOS. O objetivo é conferir a ferramenta e a identificação de quem fará os commits.

Confira a pasta deste projeto e diga se ela já pertence a um repositório Git. Verifique a versão instalada do Git e se há nome e e-mail configurados para os commits. Mostre a pasta, a versão e o resultado da identificação. Não mostre credenciais e não altere configurações globais. Se faltar Git, indique a instalação oficial para macOS e me diga o que preciso fazer. Se já houver histórico ou conexão com o GitHub, explique o que existe antes de adaptar os próximos passos desta aula.

Este projeto já existe no GitHub. Quero trazer uma cópia para este computador, preservando seu histórico. Confira o endereço do repositório, a conta e o acesso. Clone em uma pasta nova, sem sobrescrever uma pasta existente. Depois mostre a pasta criada, a linha de trabalho, os destinos e o histórico recente. Oriente em qual pasta devo continuar esta aula. Não crie outro repositório no GitHub e não envie mudanças.

Saída esperada — versão obtida no teste

git version 2.54.0 (Apple Git-157)

Seu número de versão pode ser diferente. As leituras e gravações da identificação foram conferidas na documentação. O teste original usou uma identidade fictícia somente nos comandos de commit e reversão; a revisão verificou também a gravação local dessa autoria em uma pasta descartável. Nenhum teste alterou a configuração global de autoria.

Ao fim desta Etapa:

• Você conferiu a pasta do projeto.
• O Git responde com uma versão.
• Você sabe qual nome e e-mail usará, ou sabe que ainda precisa defini-los.

Pule esta Etapa se já tem uma conta e consegue entrar nela. A conta será a dona do repositório usado no exemplo. A criação da conta foi conferida na documentação e não foi repetida no teste.

Pelo Claude Code

Vou usar uma conta pessoal do GitHub para guardar este projeto em um repositório privado. Oriente minha criação de conta no site oficial, sem pedir minha senha nem códigos de verificação no chat. Se eu já tiver conta, oriente apenas a entrada nela. Diga o que devo conferir antes de voltar à aula.

Pelo site do GitHub

1. 1

   Passo 1

   Abra Criar uma conta no GitHub (abre em nova aba) em outra aba e mantenha o guia aberto.

2. 2

   Passo 2

   Cadastre seu e-mail, escolha um nome de usuário que consiga reconhecer depois e defina a senha no próprio site.

3. 3

   Passo 3

   Complete as verificações solicitadas pelo GitHub. Se aparecer uma escolha de plano, o GitHub Free, o plano gratuito, atende ao exemplo de repositório privado desta Aula.

4. 4

   Passo 4

   Confira o nome da conta em que entrou. Depois volte à aba do guia, nesta Etapa.

Não há um Comando de terminal equivalente neste percurso: o cadastro e a verificação da conta são feitos por você no site.

Ao fim desta Etapa:

• você consegue entrar na conta correta e reconhece seu nome de usuário. Nunca cole a senha ou um código de verificação no chat.

Agora você vai autorizar o GitHub CLI a usar sua conta. Autenticação é a confirmação de que você pode acessar essa conta. O percurso abaixo usa HTTPS, a forma de conexão protegida cujo endereço começa com https://.

Confira se o GitHub CLI, comando gh, está instalado e mostre sua versão. Se faltar, oriente a instalação oficial para macOS. Depois verifique se há uma conta autenticada, sem revelar credenciais. Para conectar minha conta pessoal, prepare o login no github.com por HTTPS e pelo navegador. Diga quando preciso assumir a autorização. Não peça senha, chave nem código no chat. Ao terminar, confira a conta ativa e me mostre qual será usada para o repositório. Confira o protocolo configurado no CLI e como o Git usará essa autorização por HTTPS. Se já houver acesso por SSH, explique como adaptar este percurso antes de criar o repositório. Se precisar ajustar o auxiliar de credenciais, explique o alcance global desse ajuste e preserve configurações de acesso da empresa que já existirem.

Saída esperada — o que conferir

Na consulta de versão, obtivemos este trecho real:

gh version 2.83.1 (2025-11-13)
https://github.com/cli/cli/releases/tag/v2.83.1

Depois do login, a consulta deve indicar que a conta pretendida está autenticada e ativa no github.com, sem problema de autenticação. Não há transcrição de login nesta Aula, porque essa ação não foi executada. Confira a conta, não uma frase exata de sucesso.

Ao fim desta Etapa:

• o gh responde, a conta correta aparece ativa e você conferiu como o Git usará a autenticação por HTTPS. Ainda não criamos o repositório no GitHub.

Vamos registrar a primeira versão no computador. O exemplo usa uma pequena descrição de uma loja. No seu projeto, o Pedido deve selecionar os arquivos reais depois da revisão.

Prepare o primeiro commit deste projeto. Confira primeiro a pasta e se já existe histórico Git. Se for uma pasta nova, inicie o Git com a linha principal chamada main. Se já houver histórico, preserve-o e explique a adaptação necessária.

Crie ou complemente o .gitignore sem apagar regras existentes. Exclua .env, .env.* e arquivos de chaves ou credenciais identificados no projeto. Revise os arquivos e o conteúdo que será incluído, sem exibir valores secretos. Se algum segredo já tiver sido registrado, interrompa antes de enviar qualquer coisa e explique o problema.

Confira minha identificação de autor. Se faltar, peça somente o nome e o e-mail de autoria e configure apenas este projeto. Não mude a configuração global.

Selecione explicitamente os arquivos do projeto que passaram pela revisão, confira a seleção e faça o primeiro commit com uma mensagem clara. Não envie ao GitHub ainda. Mostre o identificador do commit, a lista de arquivos incluídos e o resultado de git status. Diga o que ficou de fora.

Saída esperada — copiada do teste local

Ao iniciar, o Git mostrou o caminho completo da pasta de teste. No seu computador, o caminho será outro:

Initialized empty Git repository in /private/tmp/claude-501/-Users-lucassales-Projects/f72649e4-473e-4d03-959c-c34b639c3f5c/scratchpad/rascunhos/aula-05/teste/.git/

Criamos .env e .env.local com valores fictícios, sem qualquer segredo, apenas para testar a exclusão. A consulta das regras devolveu:

.gitignore:1:.env	.env
.gitignore:2:.env.*	.env.local

Antes da seleção, a situação resumida mostrou apenas os dois arquivos que deveriam entrar. Os sinais ?? indicam arquivos novos ainda não acompanhados.

?? .gitignore
?? README.md

O primeiro commit, executado com a identidade temporária descrita acima, devolveu:

[main (root-commit) 39b86e6] docs: registra o início do projeto
 2 files changed, 7 insertions(+)
 create mode 100644 .gitignore
 create mode 100644 README.md

Depois, git status devolveu:

On branch main
nothing to commit, working tree clean

E git log --oneline -5 mostrou:

39b86e6 docs: registra o início do projeto

O trecho 39b86e6 é o identificador abreviado daquele commit; o seu será diferente. A mensagem “working tree clean” indica que a consulta não encontrou alterações pendentes a mostrar. Arquivos ignorados, como os .env fictícios deste teste, podem continuar na pasta sem aparecer nessa consulta. Ela não confirma envio ao GitHub nem certifica ausência de segredos. Se aparecerem outros arquivos pendentes no seu projeto, confira se devem entrar ou ficar de fora antes de avançar.

Ao fim desta Etapa:

• Existe um primeiro commit no computador.
• O .gitignore faz parte desse registro.
• Senhas, chaves, .env e suas variações ficaram de fora.
• Você sabe quais arquivos entraram e quais ainda estão pendentes.

Agora vamos criar o destino, cadastrar sua conexão e enviar os commits. São três ações: criar o repositório no GitHub, registrar seu endereço no Git e fazer push.

O desenho separa as ações para você entendê-las. O Comando de criação abaixo também cadastra a conexão origin; o push continua sendo uma ação separada.

Quero guardar este projeto no GitHub em um repositório PRIVADO chamado meu-projeto. Confira a conta ativa, a pasta, o primeiro commit, a linha de trabalho atual e se já existe um destino remoto chamado origin. Confira também que não há segredos no conteúdo nem no histórico que será enviado, sem mostrar valores secretos.

Se ainda não existir esse destino e o nome estiver disponível na minha conta, crie o repositório privado, conecte a pasta a ele como origin e envie os commits da linha atual. Se encontrar um destino existente, outra conta, repositório com conteúdo ou problema de acesso, pare e explique a situação antes de mudar a conexão. Não force o envio nem sobrescreva um destino existente.

Ao terminar, mostre o endereço do repositório, a confirmação de que é privado, qual linha foi enviada e como conferir os arquivos no navegador. Mostre também o resultado da operação de envio.

Criei um repositório privado e vazio pelo site do GitHub. O endereço HTTPS é https://github.com/SEU-USUARIO/SEU-REPOSITORIO.git. Confira que ele pertence à conta esperada e que é privado. Confira a linha local e se já existe origin, sem trocar um destino existente. Revise o histórico que será enviado para não incluir segredos. Se tudo corresponder a este projeto, conecte esse endereço como origin, envie os commits e mostre o resultado e o endereço para eu conferir no navegador. Não force o envio.

Saída esperada — o que conferir

No navegador, o repositório correto deve mostrar a identificação Private / Privado, os arquivos enviados e o commit que você acabou de registrar. Na consulta pelo CLI, o campo isPrivate deve ser true. Compare a mensagem do último commit com o histórico local. Esses são critérios de conferência baseados na documentação, não uma transcrição de envio realizado neste teste.

Ao fim desta Etapa:

• A conta e o nome do repositório estão corretos.
• O repositório está privado.
• O destino origin aponta para ele.
• Os arquivos e o commit aparecem no GitHub.
• .env, senhas e chaves ficaram fora do histórico enviado.

O que ficou guardado e o que ainda está só no computador?

O GitHub recebe o histórico enviado da linha escolhida. Arquivos ainda não registrados, arquivos ignorados e mudanças em outras linhas que você não enviou não passam a estar guardados lá só porque o push terminou. Por exemplo: um documento de requisitos registrado pode estar no GitHub; uma planilha local ignorada pode continuar existindo apenas no computador. Organize separadamente a guarda dos dados que ficaram fora do repositório.

Enviar ao GitHub já coloca o site no ar? Este percurso guarda o projeto em um repositório; ele não configura a publicação de um site. Se o repositório já estiver ligado a uma plataforma como a Vercel, que publica aplicações, um push pode acionar uma publicação automática conforme a integração e a linha escolhida. Nesse caso, conferir antes de enviar também evita publicar uma mudança ainda não aprovada. A configuração dessa integração pertence à Aula 06; não foi executada nesta Aula.

Repita o ciclo quando concluir uma mudança que faça sentido reconhecer depois: “organiza os pedidos da loja”, “corrige o cálculo do frete” ou “acrescenta o cadastro de clientes”. A rotina é conferir o trabalho, selecionar as alterações, registrar um commit e enviar.

Onde isso entra no BMAD?

Skill é um roteiro de trabalho que orienta a inteligência artificial, ou IA. No Claude Code, as instruções de uma skill ficam em um arquivo SKILL.md. No BMAD 6.12.4, a skill bmad-build pode encerrar uma mudança com um commit local, quando o Git está disponível e há alterações. O envio não acontece automaticamente: depois de conferir o resultado, você pede o push. Se o commit já foi feito, basta conferir e enviar; não há necessidade de criar outro sem mudanças.

O Pedido de rotina abaixo é uma instrução comum ao Claude Code. Você não precisa chamar uma skill do BMAD só para registrar e enviar trabalho que já está pronto.

Qual caminho usar antes de salvar?

A rotina do Git continua sendo conferir, registrar e enviar. O que muda é como você prepara e revisa o trabalho antes desse registro.

• O trabalho está pronto e falta apenas guardar: use o Pedido desta Etapa. O escopo de bmad-build exclui operações de versionamento que apenas registram trabalho existente.
• Ainda é preciso implementar uma mudança: bmad-build pode partir de uma descrição direta, como “corrigir o cálculo do frete”, ou de uma unidade de trabalho já planejada. Ao terminar, confira o commit local antes de tentar registrar novamente.
• Existe uma especificação ou um projeto maior: uma especificação descreve o resultado esperado; um épico reúne mudanças relacionadas. O trabalho pode ser dividido em várias unidades. Cada execução de bmad-build cuida de uma unidade; não é necessário esperar todo o projeto terminar para registrar avanços coerentes. A sequência de planejamento fica para a Aula 06.
• Você quer entender a mudança antes de enviar: use /bmad-walkthrough na conversa em que bmad-build terminou. Essa skill orienta sua leitura e sugere formas de observar o funcionamento. Ajuda a decidir entre aprovar, pedir ajustes ou discutir mais. Ela não executa o conjunto de testes do projeto nem substitui uma revisão técnica.
• Você precisa de uma revisão técnica adicional: a skill indicada é bmad-code-review. Depois de eventuais correções, confira novamente os arquivos e commits antes de enviar.

Um nome iniciado por /, como /bmad-walkthrough, é usado no chat, como Pedido de execução da skill. Não é um Comando para o terminal.

Mesmo no caminho autônomo bmad-build-auto, quando o controle de versões está disponível, o encerramento registra localmente o trabalho revisado e não faz push. Essa skill só deve ser usada quando chamada pelo nome; não é necessária para a rotina básica desta Aula. Todos esses caminhos do BMAD foram conferidos na fonte 6.12.4 e na instalação local, mas não foram executados nesta Aula.

Concluí e conferi esta mudança. Revise a situação do Git, os arquivos alterados e os commits que ainda precisam ser enviados. Confira se há segredos, arquivos locais ou mudanças fora desta tarefa, sem revelar valores secretos.

Se faltar registrar a mudança, selecione apenas os arquivos revisados e faça um commit com uma mensagem que explique o resultado. Se o BMAD já fez esse commit, use o registro existente.

Confira a conta, o repositório privado e o destino origin. Envie os commits da linha atual sem forçar e sem misturar trabalho de outra pessoa. Se o envio for recusado, pare e explique a causa. Mostre o commit, o resultado do envio e o endereço para eu conferir no GitHub.

Trabalho individual, equipe e mudanças simultâneas

Em um projeto individual simples, esta Aula usa uma linha, main, para tornar o ciclo visível. Se outras pessoas ou agentes trabalham ao mesmo tempo, combinem como separar e revisar as mudanças. Um caminho documentado pelo GitHub é criar uma linha para a mudança, registrar nela, enviá-la e abrir uma pull request: um pedido de revisão e integração ao projeto. Depois da revisão, a integração recebe o nome de merge.

Nesse caminho, você envia a linha da mudança; não usa automaticamente git push origin main. O repositório pode exigir revisões ou verificações antes da integração. Uma recusa pode ser uma regra de proteção funcionando, mesmo que sua conta esteja corretamente autenticada. Use a política da empresa e peça ao Claude Code que identifique as regras do projeto. Esse fluxo colaborativo não foi executado nesta Aula.

Este projeto tem trabalho simultâneo ou revisão obrigatória. Confira a pasta efetiva, a linha atual, os destinos e as regras do repositório. Explique qual linha deve receber esta mudança e como será revisada antes da integração. Preserve alterações de outras tarefas. Não envie direto para main se o fluxo exigir uma linha separada e uma pull request. Mostre os commits que pertencem a esta mudança e os passos que ainda dependem de revisão.

Saída esperada — segundo commit do teste local

Depois de acrescentar a promessa ao arquivo e registrá-la, obtivemos:

[main ca6f0e3] docs: registra entrega no mesmo dia
 1 file changed, 2 insertions(+)

O histórico consultado com git log --oneline -5 ficou assim:

ca6f0e3 docs: registra entrega no mesmo dia
39b86e6 docs: registra o início do projeto

São duas versões locais, com a mais recente em cima. Nenhuma delas foi enviada pelo teste. Na sua rotina, a conferência termina quando o commit enviado aparece também no repositório privado.

Ao fim desta Etapa:

• você sabe repetir a revisão, o commit e o push; também sabe que o commit feito pelo BMAD pode estar aguardando seu pedido de envio.

Às vezes a mudança foi registrada, mas não deveria continuar valendo. No exemplo, a loja percebe que não pode prometer todas as entregas no mesmo dia. Vamos desfazer essa última mudança mantendo o registro do que aconteceu.

Quero desfazer a última mudança registrada neste projeto, preservando o histórico. Confira git status e os últimos commits. Mostre qual é o último commit e quais alterações ele contém. Se houver alterações pendentes, união de linhas de trabalho, segredo no histórico ou se o alvo for o primeiro commit de preparação, pare e explique o cuidado necessário.

Se for a última mudança comum e não houver essas pendências, crie um novo commit que reverta seu efeito. Use a mensagem automática da reversão. Confira o resultado nos arquivos e no histórico. Não envie ainda: primeiro quero conferir o resultado. Mostre o commit criado e a situação final do Git.

Saída esperada — reversão executada no teste

[main cd853c8] Revert "docs: registra entrega no mesmo dia"
 Date: Sun Nov 15 13:42:44 2026 -0300
 1 file changed, 2 deletions(-)

O histórico passou a ter três registros:

cd853c8 Revert "docs: registra entrega no mesmo dia"
ca6f0e3 docs: registra entrega no mesmo dia
39b86e6 docs: registra o início do projeto

E git status confirmou:

On branch main
nothing to commit, working tree clean

O README.md voltou ao conteúdo anterior à promessa de entrega, e o .gitignore permaneceu no projeto. Os identificadores e a data acima pertencem ao teste; no seu projeto serão outros.

Ao fim desta Etapa:

• você sabe localizar o último commit, desfazer seu efeito com um novo registro e enviar a correção depois de conferir.

E se o que quero desfazer estiver em outra situação?

• Só selecionou o arquivo e ainda não fez commit: volte à retirada de seleção da Etapa 07. Você pode deixar o conteúdo no computador e decidir depois se ele deve entrar em outro registro.
• Editou, mas ainda não registrou: o Git não tem um commit dessa edição para reverter. Peça ao Claude Code que mostre a diferença e preserve uma cópia antes de descartar qualquer coisa. Uma edição nunca registrada pode não ser recuperável pelo Git depois de descartada.
• O commit já foi enviado: a reversão mantém o registro anterior e cria uma correção que também precisa ser enviada. Em equipe, a correção deve seguir a mesma revisão e integração das outras mudanças.
• O commit mistura uma mudança boa e outra ruim: reverter o commit inteiro pode retirar as duas. Peça uma correção focada no comportamento indesejado e confira o resultado antes de registrá-la. Isso é uma decisão sobre o conteúdo da correção; o efeito de revert é desfazer as mudanças do commit escolhido.
• O alvo é uma integração de linhas: um commit de merge tem mais de um antecedente. A reversão precisa definir qual caminho será a referência e pode afetar integrações futuras. O Comando simples desta Aula não cobre essa escolha. Peça uma análise do histórico; não copie uma opção adicional sem entender qual mudança deseja preservar.

Essas alternativas explicam quando mudar de caminho. A revisão testou a retirada de seleção e a reversão de um commit comum; descarte de edições, reversão parcial e reversão de merge não foram executados.

1. O envio foi recusado. O que fazer?

   Uma causa possível é o GitHub já ter mudanças que ainda não estão no computador. Nesse caso, o Git pode recusar o envio para preservar o trabalho existente. Também pode haver conta incorreta ou falta de permissão. Copie a mensagem de erro, retirando qualquer credencial, e peça ao Claude Code para verificar conta, destino e diferenças entre os históricos. Não force o envio.

   Peça ao Claude Code

   O envio ao GitHub foi recusado. Analise a mensagem, a conta ativa, o destino e os históricos local e remoto. Explique a causa e como preservar o trabalho dos dois lados. Não force o envio, não apague histórico e não troque o destino sem explicar a diferença encontrada. Mostre o próximo passo seguro para este caso.

   Se o erro for diferença de histórico, primeiro traga as informações do destino para poder compará-las. Fetch é buscar os registros remotos, sem integrar automaticamente as mudanças aos arquivos da linha em que você está trabalhando. No percurso main e origin desta Aula, depois de confirmar o endereço, execute:

   $git fetch origin

   $git log --oneline origin/main..HEAD

   $git log --oneline HEAD..origin/main

   origin/main é a referência local à main do destino, atualizada pela busca. A primeira consulta lista commits da linha atual que ainda não estão nessa referência; a segunda lista os que estão nela e faltam na linha atual. Os dois pontos separam os lados da comparação. Essas consultas não têm o limite de cinco registros: permitem conferir o conjunto pendente. Elas pressupõem que origin/main já exista e que esta seja a linha usada no projeto.

   • Só a primeira lista tem commits: há trabalho local ainda não presente na referência consultada. Confira todos esses commits antes de tentar enviar; o push pode levar mais de uma mudança pendente.
   • Só a segunda lista tem commits: há trabalho remoto a trazer para sua linha. Com os arquivos locais sem alterações pendentes e os commits remotos revisados, a atualização pode ser feita pelo caminho abaixo.
   • As duas listas têm commits: os históricos divergiram. É preciso decidir como integrar as duas sequências, respeitando o trabalho de todos. Use o Pedido de diagnóstico; não force o envio.
   • As duas listas estão vazias: os commits coincidem com a referência obtida na busca. Se o envio ainda falhar, investigue acesso, regras do repositório ou outra causa indicada na mensagem. Essa comparação não comprova que arquivos fora de commits foram enviados.

   Quando apenas falta trazer os commits remotos, use esta atualização restrita, somente na main e com o destino origin já conferidos:

   $git pull --ff-only origin main

   Pull é buscar e integrar alterações. A opção --ff-only permite a atualização apenas quando basta avançar sua linha para os commits já existentes no destino, sem criar um commit de integração. Se houver divergência, ela recusa a integração. Depois confira os arquivos e o funcionamento do projeto. A busca, as comparações e os dois resultados de --ff-only — avanço permitido e divergência recusada — foram testados entre repositórios locais descartáveis. Não foram testados contra o GitHub.

   Se o destino foi criado pelo site com um README próprio, ele pode ter um histórico inicial separado do seu. Esse caso não se resolve apenas repetindo push ou a atualização acima. Preserve os dois lados e peça uma análise; é por isso que a Etapa 06 pede criar o destino vazio.

2. Pediu senha no terminal. Qual senha usar?

   Não digite a senha da sua conta como senha de uma operação Git por HTTPS: o GitHub deixou de aceitar essa forma de autenticação. Volte à Etapa 04, confira gh auth status e a integração de credenciais do Passo 4. Se faltar autenticação, refaça o login pelo navegador; se o CLI já estiver autenticado, investigue o acesso do Git antes de repetir o login. Não copie uma chave de acesso para o chat para resolver a mensagem.

3. Um segredo foi enviado. Basta apagar o arquivo?

   Não. Apagar o arquivo atual, acrescentar uma regra ao .gitignore ou fazer revert não elimina o dado das versões anteriores. Revogue a credencial exposta e gere outra no serviço responsável. Depois avalie se também é necessário retirar o conteúdo do histórico. Para uma credencial, revogar ou substituir pode ser suficiente para interromper seu uso indevido; reescrever o histórico não é uma etapa automática para todos os casos. Outros dados confidenciais podem exigir uma limpeza específica. Siga a orientação oficial, considerando cópias e pessoas com acesso. Repositório privado continua exigindo esse cuidado. Não publique o segredo no chat ao pedir ajuda; informe apenas o tipo de dado e o arquivo afetado.

   Se o segredo entrou em um commit que ainda não foi enviado, interrompa o push. Um novo commit apagando o arquivo não remove o dado do commit anterior. Peça a correção do histórico local antes do primeiro envio e confira o conjunto completo que será enviado. Esses procedimentos de remoção de dados não foram executados nesta Aula.

4. O branch tem outro nome. Preciso trocar para main?

   Não automaticamente. Consulte git branch --show-current. Se o projeto já tinha uma linha chamada, por exemplo, master, peça ao Claude Code que ajuste o envio ao nome e à política daquele projeto. O main desta Aula foi uma escolha explícita na criação, não uma garantia sobre todos os repositórios. Se a consulta não mostrar nome algum, pare e peça a análise antes de enviar.

5. Já existe um origin. Posso cadastrar outro por cima?

   Primeiro consulte git remote -v e confira de quem é o endereço. origin pode já ser o destino correto ou apontar para outro projeto. Não apague nem substitua esse cadastro sem entender o caso. Se o destino certo já existe, o caminho é conferir acesso, privacidade e histórico antes de enviar.

6. A reversão parou com um conflito. Como sair?

   Conflito é uma situação em que o Git não consegue conciliar as alterações automaticamente. Pare e peça ao Claude Code que explique os arquivos envolvidos. Se a intenção for cancelar uma reversão ainda em andamento e voltar ao estado anterior a ela, existe git revert --abort. Esse cancelamento não serve para desfazer uma reversão já concluída. O caminho com conflito e seu cancelamento foram conferidos na documentação, mas não foram executados no teste.

7. “Não há nada para registrar” significa que está no GitHub?

   Não. Significa que o Git não encontrou uma nova alteração para aquele commit. Um commit anterior ainda pode estar só no computador. Confira o histórico, o resultado do push e a página do repositório.

8. O Git não reconheceu config get ou config set. Preciso começar de novo?

   Não. Pode ser uma versão anterior à sintaxe usada nesta Aula. Confira git --version. A documentação também mantém as formas antigas: git config --get user.name e git config --get user.email para consultar; git config --local user.name "SEU NOME" e git config --local user.email "SEU EMAIL DE AUTORIA" para definir. A gravação continua exigindo que o repositório já exista. Essas formas foram verificadas com o Git do teste; não executamos a Aula em versões antigas. Se o erro for outro, use a mensagem para diagnosticar antes de modificar a configuração.