Git é uma das ferramentas mais importantes no desenvolvimento de software. Ele permite acompanhar as alterações realizadas em um projeto, recuperar versões anteriores e trabalhar em equipe sem que cada desenvolvedor precise manter sua própria cópia desconectada do código. Apesar de comandos como `commit`, `branch`, `merge` e `push` aparecerem o tempo todo no dia a dia de quem programa, entender **o que o Git está fazendo por trás desses comandos** torna seu uso muito mais simples. Neste tutorial, vamos conhecer os principais conceitos do Git e criar um pequeno fluxo de trabalho do zero. --- ## O que é Git? Git é um **sistema de controle de versão distribuído**. Na prática, ele registra a evolução dos arquivos de um projeto ao longo do tempo. Imagine que temos um arquivo: ```text index.html ``` Depois de algumas alterações, poderíamos ter algo conceitualmente parecido com: ```text Versão 1 → Página criada Versão 2 → Adicionado menu Versão 3 → Adicionado formulário Versão 4 → Corrigido bug no formulário ``` O Git permite registrar esses estados e, se necessário, voltar a algum deles. Isso também possibilita que várias pessoas trabalhem no mesmo projeto mantendo históricos de alterações independentes que depois podem ser combinados. --- ## Git não é GitHub Antes de continuar, é importante separar dois conceitos que costumam gerar confusão. **Git** é a ferramenta de controle de versão. **GitHub** é uma plataforma que hospeda repositórios Git. Existem diversas plataformas desse tipo, como: - GitHub - GitLab - Bitbucket - Azure DevOps Você pode usar Git normalmente sem utilizar nenhuma dessas plataformas. --- ## Instalando o Git Antes de começar, precisamos instalar o Git no computador. O instalador oficial pode ser baixado em: [https://git-scm.com/downloads](https://git-scm.com/downloads) Escolha a versão correspondente ao seu sistema operacional e siga as etapas do instalador. No Windows, para este tutorial, as opções padrão do instalador são suficientes. Depois da instalação, abra um terminal e execute: ```bash git --version ``` O resultado será semelhante a: ```text git version 2.51.0 ``` Também é recomendável configurar seu nome e e-mail. ```bash git config --global user.name "Seu Nome" git config --global user.email "seu@email.com" ``` Essas informações serão associadas aos commits criados por você. Para visualizar as configurações: ```bash git config --list ``` --- ## O que é um repositório? Um **repositório Git** é um diretório cujo histórico está sendo controlado pelo Git. Vamos criar um pequeno projeto: ```bash mkdir meu-projeto cd meu-projeto ``` Agora inicializamos o Git: ```bash git init ``` O Git criará internamente um diretório oculto chamado: ```text .git ``` É nesse diretório que ficam armazenadas informações como: - commits; - branches; - referências; - configurações; - histórico do repositório. Nosso diretório agora é um repositório Git. --- ## Os três estados principais do Git Um dos conceitos mais importantes para entender Git é que um arquivo pode passar por diferentes estados. De forma simplificada, podemos imaginar: ```text Working Directory ↓ Staging Area ↓ Repository ``` ### Working Directory É o diretório onde estamos trabalhando normalmente. Se alterarmos um arquivo: ```text index.html ``` essa alteração existe apenas no nosso diretório de trabalho. ### Staging Area A **Staging Area** é uma área intermediária onde escolhemos quais alterações farão parte do próximo commit. Utilizamos: ```bash git add ``` para adicionar alterações nessa área. ### Repository Quando executamos: ```bash git commit ``` as alterações presentes na Staging Area são registradas no histórico do repositório. Portanto, um fluxo bastante comum é: ```text editar arquivo ↓ git add ↓ git commit ``` --- ## Verificando o estado do repositório Um dos comandos mais utilizados no Git é: ```bash git status ``` Ele mostra o estado atual do repositório. Vamos criar um arquivo: ```bash echo "# Meu Projeto" > README.md ``` Agora: ```bash git status ``` O Git mostrará que existe um arquivo ainda não rastreado: ```text Untracked files: README.md ``` Um arquivo **untracked** é um arquivo que existe no diretório, mas ainda não está sendo acompanhado pelo Git. --- ## Adicionando arquivos à Staging Area Para adicionar o arquivo: ```bash git add README.md ``` Executando novamente: ```bash git status ``` veremos algo semelhante a: ```text Changes to be committed: new file: README.md ``` Agora o arquivo está preparado para fazer parte do próximo commit. Também podemos adicionar todas as alterações do diretório atual: ```bash git add . ``` Esse comando é bastante utilizado, mas deve ser usado com atenção para não adicionar arquivos indesejados ao commit. --- ## O que é um commit? Um **commit** representa um ponto no histórico do projeto. Podemos pensar nele como um registro contendo: ```text Commit ├── alterações ├── autor ├── data ├── mensagem └── referência ao commit anterior ``` Para criar nosso primeiro commit: ```bash git commit -m "Adiciona README inicial" ``` Agora o Git registrou esse estado do projeto. Se fizermos novas alterações, poderemos criar novos commits. Por exemplo: ```bash echo "Projeto utilizado para estudar Git." >> README.md ``` Adicionamos a alteração: ```bash git add README.md ``` E criamos outro commit: ```bash git commit -m "Adiciona descrição do projeto" ``` Agora temos dois pontos no histórico. --- ## Visualizando o histórico Para visualizar os commits: ```bash git log ``` O resultado será parecido com: ```text commit 91fa57d... Author: Seu Nome Date: ... Adiciona descrição do projeto commit 132ac91... Author: Seu Nome Date: ... Adiciona README inicial ``` Cada commit possui um identificador único, chamado **hash**. Por exemplo: ```text 91fa57db762afe32... ``` Normalmente não precisamos utilizar o hash inteiro. Uma visualização mais compacta pode ser obtida com: ```bash git log --oneline ``` Exemplo: ```text 91fa57d Adiciona descrição do projeto 132ac91 Adiciona README inicial ``` --- ## Entendendo branches Uma **branch** representa uma linha de desenvolvimento. Imagine que nosso histórico esteja assim: ```text A ── B ── C ``` Agora queremos desenvolver uma nova funcionalidade sem alterar diretamente a linha principal. Criamos uma branch: ```text D ── E / A ── B ── C ``` A branch principal normalmente é chamada: ```text main ``` Podemos verificar as branches existentes com: ```bash git branch ``` Para criar uma nova branch: ```bash git branch feature-login ``` E para mudar para ela: ```bash git switch feature-login ``` Também podemos criar e acessar a branch em um único comando: ```bash git switch -c feature-login ``` Agora os commits realizados serão associados à branch `feature-login`. Por exemplo: ```bash git add . git commit -m "Adiciona formulário de login" ``` Nosso histórico poderia ficar assim: ```text main A ── B ── C \ D \ feature-login ``` --- ## Merge: juntando branches Depois de terminar uma funcionalidade, normalmente queremos integrá-la à branch principal. Primeiro voltamos para `main`: ```bash git switch main ``` Depois executamos: ```bash git merge feature-login ``` O Git combina o histórico da outra branch com a branch atual. Conceitualmente: ```text D ── E / \ A ── B ── C ─── F ``` Onde `F` pode representar o commit resultante da integração. Depois disso, se a branch não for mais necessária, podemos removê-la: ```bash git branch -d feature-login ``` --- ## Conflitos de merge Nem sempre o Git consegue combinar alterações automaticamente. Imagine que duas branches modificaram a mesma linha de um arquivo. O Git poderá gerar um conflito semelhante a: ```text <<<<<<< HEAD

Minha aplicação

=======

Meu sistema

>>>>>>> feature-home ``` Você precisará decidir qual versão deve permanecer. Por exemplo: ```html

Minha aplicação

``` Depois de corrigir o arquivo: ```bash git add index.html git commit ``` O conflito estará resolvido. Conflitos fazem parte do funcionamento normal do Git e não significam que o repositório foi corrompido. --- ## Repositório local e remoto Até agora todo o nosso histórico existe apenas no computador. Podemos associar o repositório local a um **repositório remoto**, como um projeto hospedado no GitHub. O remoto normalmente recebe o nome: ```text origin ``` Para adicionar um repositório remoto: ```bash git remote add origin https://github.com/usuario/meu-projeto.git ``` Podemos verificar os remotos configurados com: ```bash git remote -v ``` --- ## Enviando commits com push Para enviar commits do repositório local para o remoto utilizamos: ```bash git push ``` Na primeira vez, normalmente associamos nossa branch local à branch remota: ```bash git push -u origin main ``` Depois disso, geralmente basta: ```bash git push ``` O fluxo fica assim: ```text Working Directory ↓ git add ↓ Staging Area ↓ git commit ↓ Repository local ↓ git push ↓ Repository remoto ``` --- ## Clonando um repositório Se o projeto já existe remotamente, não precisamos executar `git init`. Podemos cloná-lo: ```bash git clone https://github.com/usuario/meu-projeto.git ``` O Git criará o diretório do projeto e baixará: - arquivos; - commits; - branches; - histórico; - configuração do remoto. Depois: ```bash cd meu-projeto ``` E podemos começar a trabalhar normalmente. --- ## Atualizando o repositório com pull Quando outras pessoas enviam alterações para o repositório remoto, precisamos trazer essas alterações para nossa máquina. Para isso utilizamos: ```bash git pull ``` De forma simplificada: ```text Repository remoto ↓ git pull ↓ Repository local ↓ Working Directory ``` Assim nosso projeto local fica atualizado com as alterações existentes no remoto. --- ## Fetch e pull Outro comando importante é: ```bash git fetch ``` Ele consulta o repositório remoto e baixa informações sobre as alterações, mas não modifica imediatamente nossa branch atual. Já: ```bash git pull ``` busca as alterações e tenta integrá-las à branch atual. De maneira simplificada: ```text git fetch ↓ busca alterações git pull ↓ busca + integra alterações ``` O `fetch` é útil quando queremos primeiro verificar o que mudou antes de atualizar nossa branch. --- ## Visualizando alterações com diff O comando: ```bash git diff ``` mostra as diferenças entre os arquivos modificados e o último estado conhecido pelo Git. Por exemplo: ```diff -

Meu site

Minha aplicação

``` Se o arquivo já estiver na Staging Area: ```bash git diff --staged ``` Isso permite revisar exatamente o que será incluído no próximo commit. --- ## Ignorando arquivos com .gitignore Nem todos os arquivos de um projeto devem ser versionados. Alguns exemplos comuns: ```text node_modules/ .env dist/ build/ *.log ``` Podemos criar um arquivo chamado: ```text .gitignore ``` E adicionar: ```gitignore node_modules/ .env dist/ *.log ``` O Git passará a ignorar esses arquivos e diretórios. Isso é especialmente importante para arquivos como `.env`, que podem conter informações sensíveis: ```text DATABASE_PASSWORD API_KEY TOKEN ``` Esses dados não devem ser enviados para o repositório. --- ## Um fluxo de trabalho completo Vamos imaginar que você recebeu uma tarefa para criar uma página de login. Primeiro atualizamos a branch principal: ```bash git switch main git pull ``` Criamos uma nova branch: ```bash git switch -c feature/login ``` Desenvolvemos a funcionalidade. Depois verificamos as alterações: ```bash git status ``` Podemos revisar o código modificado: ```bash git diff ``` Adicionamos as alterações desejadas: ```bash git add . ``` Criamos um commit: ```bash git commit -m "Adiciona página de login" ``` Enviamos a branch para o remoto: ```bash git push -u origin feature/login ``` Depois da revisão e aprovação da alteração, ela poderá ser integrada à `main`. Esse é, com algumas variações, um dos fluxos mais comuns encontrados em projetos profissionais. --- ## Principais comandos Depois de entender os conceitos, os comandos começam a fazer muito mais sentido. ```bash # Inicializar um repositório git init # Clonar um repositório git clone URL # Verificar alterações git status # Ver diferenças git diff # Adicionar arquivo à Staging Area git add arquivo # Adicionar todas as alterações git add . # Criar commit git commit -m "Mensagem" # Visualizar histórico git log # Histórico resumido git log --oneline # Listar branches git branch # Criar e acessar uma branch git switch -c nome-da-branch # Trocar de branch git switch nome-da-branch # Combinar branches git merge nome-da-branch # Buscar alterações remotas git fetch # Atualizar branch local git pull # Enviar commits git push ``` --- ## O modelo mental mais importante Se você está começando com Git, tente memorizar menos comandos e entender primeiro este fluxo: ```text Arquivos modificados ↓ git add ↓ Staging Area ↓ git commit ↓ Histórico local ↓ git push ↓ Repositório remoto ``` E quando estiver trabalhando em equipe: ```text git pull ↓ criar branch ↓ editar arquivos ↓ git add ↓ git commit ↓ git push ↓ Pull Request ↓ merge ``` Quando esse modelo mental estiver claro, grande parte dos comandos do Git deixa de parecer uma coleção de instruções isoladas e passa a representar operações sobre o histórico do projeto. --- ## Conclusão Git pode parecer complicado no início principalmente porque existem muitos comandos e termos diferentes. Mas os conceitos fundamentais são relativamente simples: - arquivos são modificados no **Working Directory**; - `git add` prepara alterações na **Staging Area**; - `git commit` registra um estado no histórico; - **branches** permitem criar linhas independentes de desenvolvimento; - `merge` combina essas linhas; - `pull` traz alterações do repositório remoto; - `push` envia seus commits; - plataformas como GitHub hospedam e facilitam a colaboração sobre repositórios Git. Depois de dominar esse fluxo básico, conceitos mais avançados como `rebase`, `cherry-pick`, `stash`, `reset` e `reflog` ficam muito mais fáceis de compreender. O mais importante é lembrar que Git não é apenas uma ferramenta para "salvar código". Ele é, essencialmente, uma ferramenta para **construir e manipular o histórico de um projeto**.

Programação

Git para iniciantes: principais conceitos e comandos com exemplos práticos