Por que todo projeto precisa de controle de versão
A pasta cheia de arquivos "final"
Imagine uma pasta de projeto assim:
app_controller.rb
app_controller_v2.rb
app_controller_v2_FINAL.rb
app_controller_v2_FINAL_corrigido.rb
app_controller_v2_FINAL_corrigido_AGORA_SIM_FINAL.rb
Assim fica o desenvolvimento sem controle de versão. Não há registro do porquê de cada mudança nem jeito de ver o código da última terça-feira, e o desastre é garantido quando duas pessoas editam o mesmo arquivo. O Git substitui essa pasta inteira por um único histórico que nunca mente para você.
O que o Git rastreia
O Git tira uma fotografia (snapshot) do seu projeto inteiro toda vez que você manda ele fazer isso (essa ação se chama commit). Cada fotografia aponta de volta para a anterior, formando uma linha do tempo:
commit A ──▶ commit B ──▶ commit C ──▶ commit D (estado atual)
"init" "add users" "fix typo" "add tests"
Nada é sobrescrito silenciosamente. Você pode pular para qualquer ponto dessa linha do tempo, comparar dois pontos quaisquer, ou descobrir qual commit introduziu um bug. Uma pasta de arquivos renomeados à mão não oferece nada disso.
Por que o Git, especificamente
Sistemas de controle de versão existiam antes do Git, mas o Git venceu por motivos concretos que importam para o seu dia a dia:
- Distribuído: todo clone de um repositório carrega o histórico inteiro, não só a fotografia mais recente. Seu notebook tem um backup completo e independente no momento em que você clona.
- Rápido: quase toda operação (commit, branch, diff) roda no seu disco local: sem ida e volta pela rede.
- O padrão da indústria: GitHub, GitLab e Bitbucket são construídos sobre o Git. Pull requests, code review, pipelines de CI/CD e hooks de deploy, tudo depende do histórico do Git.
Toda equipe Rails profissional que você vai integrar usa o Git. Todo o resto do ciclo de vida do software se apoia nele.
Cinco palavras que você vai usar todo dia
| Termo | Significado |
|---|---|
| Repositório (repo) | O histórico completo de um projeto, rastreado pelo Git |
| Commit | Uma fotografia salva do projeto, com uma mensagem explicando o porquê |
| Working tree (árvore de trabalho) | Os arquivos de verdade no disco, do jeito que você está editando agora |
| Staging area (área de stage) | Um espaço intermediário onde você escolhe quais mudanças entram no próximo commit |
| Branch (ramificação) | Uma linha independente de commits, para você trabalhar em algo sem mexer no histórico principal |
Este curso cobre os três primeiros; branches ganham um curso inteiro só delas, mais adiante no roteiro.
Confira o que você tem
O Git vem junto com as ferramentas de build que você instalou no seu curso de ambiente. Confirme que ele está lá:
git --version
git version 2.43.0
Qualquer versão 2.3x ou mais nova funciona bem para tudo nesta série.
Como este curso está organizado
git init: transformar uma pasta em um repositório, e ver o que isso criagit config: dizer ao Git quem você é, para que todo commit carregue um autor de verdade.gitignore: dizer ao Git o que nunca olhar- Inspecionando um repositório:
status,logediff - Múltiplas identidades: configuração separada para projetos de trabalho e pessoais
- Montando do zero o histórico Git de um projeto Rails de verdade
No final, todo projeto novo que você começar vai ter um histórico Git corretamente inicializado e corretamente identificado desde o primeiro arquivo.
Vamos criar seu primeiro repositório.
Continue com a aula 2
git init: anatomia de um repositório
O que o git init cria na pasta .git, os três estados de um arquivo e o branch padrão.
Com uma conta grátis você também tem os quizzes, seu progresso e suas anotações, e a discussão.