1 aula em vídeo · ~11 min

Git
no Xperiun OS

Sua versão do projeto, sempre em dia.

O Leo desenvolve novidades no Xperiun OS o tempo todo: skills novas, ajustes em contexto, princípios atualizados, funis novos. Pra essas mudanças aparecerem na sua máquina, você precisa puxar o que tá no GitHub. Esse curso te dá a operação dia a dia pra manter o projeto sincronizado, sem mistério e sem bagunçar o que você criou local.

1 aula publicada Mais a caminho Pré-requisito: ter o projeto clonado
Sumário

O que tem aqui

Disponível agora
Próximos capítulos
Introdução

Como usar essa apostila

Essa apostila acompanha os vídeos do curso. Cada aula tem o vídeo embedado no topo da seção e o texto rico abaixo. Serve tanto pra assistir quanto pra consultar depois sem precisar rebobinar (tipo "como era mesmo o caminho pra puxar?").

Por que esse curso existe separado

Você já fez o curso de Claude Code no Xperiun OS. Lá você aprendeu a instalar, clonar o projeto, rodar skills e criar suas próprias. Esse curso aqui é a operação contínua: como manter o ambiente atualizado conforme o Leo evolui o projeto, e — em capítulos futuros — como contribuir de volta sem quebrar o que os outros estão fazendo.

Hoje tem 1 aula publicada (puxar novidades). Push, conflitos e branches vêm em vídeos novos quando a operação amadurecer. Quando subir aula nova aqui, o aviso vai no Google Chat.

Pré-requisito

Antes de começar

Você precisa ter o projeto Xperiun OS já clonado na sua máquina e estar com o VSCode + extensão Claude Code rodando. Se ainda não tiver, volta primeiro no curso Claude Code no Xperiun OS (Aulas 2 a 4 cobrem instalação e clone).

Convenções

Aula 1 · 11 min

Como puxar as novidades do projeto · git pull

⏱ 11 min · ↗ Abrir no YouTube

O Leo evolui o projeto direto: novas skills, ajustes em contexto, funis novos, princípios atualizados. Se você não puxar essas mudanças, sua versão fica congelada num passado que ninguém mais usa. Essa aula mostra o caminho mais simples pra trazer tudo pra sua máquina, e o que fazer quando o Git avisar que tem conflito.

O mapa mental · Git, GitHub e a sua máquina

Antes do passo a passo, vale entender as três peças que estão no jogo. Muita gente confunde elas (até o nome é parecido), mas são coisas diferentes com papéis bem distintos:

O motor

Git

O sistema de controle de versão. Imagina o "Salvar como v2, v3, v4_final, v5_final_real" do Word, mas inteligente: ele guarda cada versão do projeto e sabe exatamente o que mudou de uma pra outra. Roda na sua máquina. Não tem cara, é só um motor.

A nuvem

GitHub

Um site (github.com) onde mora a versão oficial do projeto. Funciona tipo um Google Drive especializado: todo mundo do time aponta pra ele, baixa de lá, manda pra lá. É o ponto de encontro.

Sua cópia

Sua máquina

A pasta do Xperiun OS no seu PC é uma cópia local do que tá no GitHub. Ela só fica em sincronia com a nuvem se você mandar — automaticamente nada acontece. Se ficar uma semana sem puxar, sua cópia fica uma semana atrasada.

Agora o desenho do fluxo: quem manda o quê pra onde. O Leo desenvolve novidades no PC dele e empurra pro GitHub. Você (e todos os colegas do time) puxam dali pra ter a versão atualizada na sua máquina:

PC do Leo
desenvolve · skills, contexto, funis
PUSH (empurra)
GitHub
github.com · versão oficial na nuvem
PULL (puxa)
Você
cópia local
Colega
cópia local
Colega
cópia local
Colega
cópia local
Push = empurrar mudanças do PC pro GitHub. Por enquanto só o Leo faz.
Pull = puxar mudanças do GitHub pro PC. Todo mundo do time faz.
Por enquanto · só pull

Por enquanto só o Leo faz push. Você só faz pull. O fluxo de você contribuir de volta (push) tem mais detalhes (branches, revisão, conflitos) e vai entrar num próximo capítulo do curso, quando a operação amadurecer. Tudo que você fizer local fica local e ninguém mais vê — sem risco de quebrar o projeto pros outros.

Duas contas diferentes · não confunde

Antes de mexer em qualquer coisa, vale separar as duas contas que você usa no dia a dia. Elas parecem a mesma coisa porque ambas vivem no VSCode, mas são empresas diferentes, com senhas diferentes:

  1. Conta Anthropic (Claude Code) — sua conta pessoal/individual. É com ela que você loga no Claude no canto direito do VSCode pra usar a IA. Cada pessoa do time tem a sua, foram liberadas individualmente.
  2. Conta GitHub — usa o e-mail compartilhado acessos@xperiun.com. É com ela que o VSCode autentica pra puxar/empurrar código no GitHub.
Por que separar

A conta da Anthropic foi bloqueada uma vez no passado por estar sendo usada como compartilhada. Por isso hoje cada pessoa loga com a sua. Se aparecer alguma tela de "não autorizado" no Claude, confere se você está na sua conta pessoal e não na acessos@xperiun.com.

Caminho mais fácil · pedir pro Claude

O VSCode tem o painel de Source Control (ícone de bifurcação na barra lateral esquerda) com botões pra fazer pull, mas a interface é cheia de termos técnicos em inglês e fica confusa rápido. O caminho mais simples no Xperiun OS é pedir direto pro Claude Code, em português:

puxa as novidades do GitHub

Ele entende que isso é um git pull, executa o comando por você, e te avisa o que aconteceu. Resposta típica vai ser algo assim:

Puxei as novidades. Foram baixados 47 arquivos novos:
- 3 skills novas em .claude/skills/
- 12 atualizações em contexto/
- 1 funil novo em producao/funis-xperiun/
Sua versão local agora está em dia com a main.

Se tiver conflito, ele lista exatamente o que conflitou e te dá as opções pra escolher (a próxima seção mostra como decidir).

Outras frases que funcionam igual

traz as novidades do projeto · atualiza o projeto com o que tá no GitHub · faz pull do main. Todas chegam no mesmo lugar. O Claude entende a intenção, não precisa decorar comando técnico.

Se preferir o botão

Pra quem gosta da interface visual: Source Control (ícone de bifurcação na esquerda) → setinha pra baixo no botão dos três pontos no topo → "Pull from..." → escolhe origin/main. Funciona igual, só é mais clique. Em compatibilidade futura é capaz que essa interface mude — o caminho via Claude é mais estável.

Quando o Git pede pra escolher · conflito

Conflito acontece quando você modificou um arquivo localmente e esse mesmo arquivo também foi modificado lá no GitHub. O Git não sabe qual versão você quer manter, então pergunta. Pensa nele como um colega cuidadoso que prefere parar e te chamar do que decidir sozinho e talvez apagar algo que você queria.

Geralmente o Claude vai te oferecer três opções. Aqui vai a regra de bolso de qual escolher:

  1. Guardar suas mudanças locais e aplicar depois (em inglês: stash + pull + pop) — opção recomendada na maioria dos casos. Suas alterações ficam preservadas num "bolso", o pull entra por cima trazendo as novidades, e depois suas mudanças voltam por cima já em sintonia com a versão atualizada.
  2. Descartar mudanças locais — perde tudo que você fez local naquele arquivo. Só usa quando tiver certeza absoluta que era lixo mesmo (ex: você mexeu por engano num arquivo de configuração e quer voltar pro padrão). Não tem volta.
  3. Ver o que mudou — útil pra entender a diferença antes de decidir. O Claude mostra um diff (comparação lado a lado) explicando o que tá local vs o que tá vindo do GitHub. Bom pra casos onde você não lembra o que mexeu.
A pergunta que te tira da dúvida

"Se eu perder o que fiz local agora, isso me dói?" Se a resposta for sim, vai na opção 1 (preservar). Se não importa, opção 2 (descartar). Na dúvida, sempre opção 1 — preservar é reversível, descartar não.

Se travar de verdade ou ficar inseguro, manda print no Google Chat que a gente desbloqueia em segundos. É preferível parar 2 minutos pra perguntar do que perder uma hora de trabalho.

Importante · suas criações locais ficam locais

Tudo que você criar dentro do projeto na sua máquina — uma carta nova, uma pauta semanal, um carrossel de teste, qualquer arquivo — fica só na sua máquina. Não vai automaticamente pro GitHub. Outras pessoas do time não conseguem ver.

Isso é proposital por enquanto: enquanto a equipe tá aprendendo, deixar tudo local evita que alguém empurre algo quebrado e bagunce a versão de todo mundo. Quando o time amadurecer no fluxo, o Leo vai liberar o push e gravar o capítulo de "contribuindo com o repo".

Quando puxar

Mini-glossário · termos pra consulta rápida

Você não precisa decorar nada disso. Mas alguns termos vão aparecer no chat com o Claude (ou em conversas com o Leo) e é bom ter ideia do que significam:

repositório (repo) A pasta versionada inteira. O Xperiun OS é um repo. "Clonar o repo" = baixar essa pasta pra sua máquina.
commit Uma "foto" do projeto num momento específico, com uma mensagem descrevendo o que mudou. Cada vez que o Leo manda novidades, ele faz 1 ou mais commits.
push Empurrar seus commits do PC pro GitHub. Por enquanto, só o Leo faz.
pull Puxar commits do GitHub pro seu PC. Você faz toda vez que o Leo avisar no Chat.
main O "galho principal" do projeto · a versão oficial que vale pra todo mundo. Quando você puxa, normalmente puxa do main.
branch (galho) Uma versão paralela do projeto pra você experimentar sem afetar o main. Tema do próximo capítulo do curso.
conflito Quando duas mudanças no mesmo arquivo precisam de uma decisão humana ("qual versão fica?"). O Git te avisa, você escolhe.
diff A "comparação" entre duas versões de um arquivo. Mostra o que foi adicionado, removido e mudado, lado a lado.
Resumo em 30 segundos

Git é o motor (controle de versão), GitHub é a nuvem (versão oficial), sua pasta no PC é uma cópia local que precisa ser sincronizada. Conta da Anthropic é sua, pessoal. Conta do GitHub é compartilhada (acessos@xperiun.com). Pra puxar novidades, abre o Claude e fala puxa as novidades do GitHub. Se aparecer conflito, na dúvida vai na opção preservar local (opção 1). Tudo que você cria local fica local — push vem em capítulo futuro. Avisos de novidade vêm pelo Google Chat.

Próximos capítulos

O que vem por aí

Esse curso vai crescer conforme a operação da equipe amadurecer no Git. A ideia é cobrir cada novo passo do fluxo no momento certo, sem despejar tudo de uma vez.

Próximas aulas no roadmap

  1. Contribuindo com o repo · seu primeiro push — quando você tiver à vontade puxando novidades, vamos pro outro lado: como mandar suas próprias mudanças pro GitHub sem quebrar nada de quem tá usando.
  2. Conflitos · quando o Git pede sua opinião — aprofundamento de conflitos. Casos reais, como ler o que o Git tá mostrando, quando manter local vs remoto, quando juntar os dois.
  3. Branches · trabalhando em paralelo sem atrapalhar ninguém — o conceito de branch (galho), por que existe, quando você precisa abrir uma, como mesclar de volta na principal.
Sem pressa

Domina o pull primeiro. Faz isso virar automático na sua semana. Quando o capítulo de push subir, você já vai estar com o fundamento certo pra entender o resto sem confusão.