Trabalhando com o Git
Imagine que você começou seu dia de trabalho. Você tem um projeto com alguns arquivos e precisa fazer alguma coisa (adicionar uma funcionalidade nova, corrigir um bug etc.). E também quer manter tudo sob controle de versão.
Como resultado, alguns arquivos novos serão criados, e alguns arquivos existentes serão modificados ou excluídos. O diretório de trabalho (working tree) do seu projeto vai mudar.
Ah, aliás, esse é o jargão do Git para os arquivos do projeto. Vamos parar um instante para entender isso.
O (em inglês, working tree ou working directory) é o conjunto real de arquivos do seu projeto no estado atual deles. É a versão do projeto que você vê na sua frente e com a qual trabalha. Quando alguém fala em alterações no diretório de trabalho, quer dizer alterações que você fez nos arquivos, mas ainda não salvou no Git. Isso pode incluir arquivos novos, modificações e exclusões.
Então, você trabalhou no projeto e agora tem algumas alterações no diretório de trabalho. Chegou a hora de salvar seu progresso. Mas, antes disso, você precisa revisar essas alterações e decidir quais quer manter.
Nesse ponto, o Git pode mostrar quais arquivos mudaram e quais linhas desses arquivos foram adicionadas, removidas ou modificadas. Você pode revisar essas alterações, adicionar as que quiser à staging area e descartar as que não quiser.
A (área de preparação) é a memória de curto prazo do Git: é onde ele registra quais alterações você selecionou para o próximo snapshot do projeto (chamado de commit no vocabulário do Git; já vamos falar mais dele).
Digamos que passei o dia inteiro trabalhando em uma mudança grande no projeto e, agora que terminei, quero salvar essas alterações de forma permanente no histórico do projeto. Quero criar um do Git, um snapshot do estado atual dos arquivos do projeto. Depois de criado, o commit vira parte do histórico do projeto e não pode ser alterado nem excluído facilmente.
Mas, antes de criá-lo, você precisa decidir exatamente quais alterações devem entrar no próximo commit. Na maioria das vezes, são todas as alterações que você fez. Mas às vezes é melhor dividi-las em vários commits para manter o histórico do projeto organizado. Nesse caso, você adiciona só uma parte das alterações à staging area, faz o commit e repete o processo com o resto.
Analogia: você lavou o carro e também completou a água do limpador de para-brisa. São duas mudanças independentes, então é melhor commitá-las separadamente. Senão, o histórico de mudanças do reservatório do limpador vai ter uma entrada "Lavei o carro", que não corresponde ao que mudou de verdade e pode confundir quem ler esse histórico mais tarde.
Depois de escolher e organizar as alterações que quer manter, só falta criar o commit em si. Como parte do commit, você também pode deixar uma descrição explicando exatamente o que mudou e por quê. Isso deixa o histórico do projeto mais fácil de entender quando você ou outra pessoa olhar para ele mais tarde. Quando o commit é criado, essas alterações ficam salvas de forma permanente no repositório do Git (mais jargão do Git para "histórico do projeto").
Um é a memória de longo prazo do Git. Cada commit que você faz vira parte do repositório.
Alguns commits podem fazer parte do histórico principal do projeto, outros podem pertencer a branches experimentais, outros podem ser commits temporários que você descarta depois, e assim por diante. Um commit pode ser tão pequeno quanto a correção de um erro de digitação em uma única linha de código, ou tão grande quanto uma funcionalidade inteira nova com centenas de arquivos alterados.
O repositório fica armazenado no diretório .git, na raiz do seu projeto. Tenha em mente que esse diretório fica oculto por padrão. Danificar ou excluir esse diretório corrompe seu repositório Git local.
Você pode parar por aqui e ter um histórico local completo do projeto, mas um próximo passo comum é enviar e puxar alterações de um repositório remoto — o famoso push e pull.
Se você trabalha em equipe, é assim que compartilha suas alterações e recebe as atualizações das outras pessoas. Seus commits novos serão enviados ao repositório remoto, e você vai baixar os commits que seus colegas subiram desde a última sincronização.
Se você trabalha por conta própria, ainda tem a vantagem de não perder seu trabalho se algo acontecer com o computador, e pode acessar o projeto de qualquer dispositivo. Também dá para compartilhar seu código com outras pessoas dando a elas acesso ao repositório remoto.
-
Volte ao Passo 2 se tiver outro código pronto para ser salvo no histórico do projeto. Adicione mais alterações ao stage e faça o commit. Se precisar, você também pode descartar as alterações que ficaram fora do stage.
-
Volte ao Passo 1 se quiser continuar trabalhando no projeto, fazendo mais alterações no diretório de trabalho.
No começo, tudo isso pode parecer meio confuso, principalmente se você nunca trabalhou com controle de versão. Mas, com o tempo, o processo vai ficando natural, e uma hora você vai fazer a maior parte dele quase no automático.
Faça o curso do jeito que ele foi pensado: progressão em pequenas doses, ordem linear e focada, desbloqueio gradual das entradas da Gitopedia. Continue com o Git de verdade no VS Code/Cursor/Antigravity/Windsurf a qualquer momento.
mas precisa de login