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.
Enquanto você trabalha, alguns arquivos novos são criados, e alguns dos que já existem são modificados ou excluídos. Com isso, o diretório de trabalho (working tree) do projeto muda.
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.
Depois de trabalhar no projeto, você tem algumas alterações no diretório de trabalho. Chegou a hora de salvar seu progresso. Mas, antes disso, precisa revisar essas alterações e decidir quais quer manter.
Nessa etapa, o Git mostra quais arquivos mudaram e quais linhas foram adicionadas, removidas ou modificadas. Você pode revisar as alterações, adicionar as que quiser à staging area e descartar o resto.
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. No commit, você também pode deixar uma descrição explicando exatamente o que mudou e por quê. Assim, fica mais fácil entender o histórico do projeto quando você ou outra pessoa consultá-lo 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. Lembre que esse diretório fica oculto por padrão. Danificá-lo ou excluí-lo corrompe seu repositório Git local.
Você pode parar por aqui e ter um histórico local completo do projeto, mas o passo seguinte costuma ser enviar e puxar alterações de um repositório remoto — os famosos 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: avance aos poucos, siga uma sequência linear, mantenha o foco e desbloqueie gradualmente as entradas da Gitopedia. Quando quiser, continue praticando com o Git de verdade no VS Code, Cursor ou Antigravity IDE.
mas precisa de login