Post

Tutorial Completo de Git: Do Básico ao Avançado

Aprenda o uso do Git, do controle de versão básico a funcionalidades avançadas, com práticas recomendadas e resolução de problemas comuns.

Posted
By Gean Martins
57 min read
Tutorial Completo de Git: Do Básico ao Avançado

Introdução

O git é uma das ferramentas mais poderosas e essenciais no desenvolvimento de software, permitindo o controle de versões, a colaboração eficaz e o gerenciamento de alterações em projetos. Criado por Linus Torvalds, o git se destaca por ser um sistema de controle de versão distribuído, onde cada desenvolvedor possui uma cópia completa do repositório, garantindo segurança e flexibilidade no desenvolvimento de projetos de qualquer escala.

Neste tutorial, abordaremos desde os conceitos básicos até funcionalidades avançadas do git, explorando como essa ferramenta possibilita fluxos de trabalho organizados e colaborativos. O conteúdo está estruturado para guiar usuários de todos os níveis de experiência, passando por comandos iniciais, como a criação de commits e branches, até técnicas mais avançadas, como o uso de patches e a resolução de conflitos.

Seja você um iniciante em controle de versão ou um desenvolvedor experiente, este tutorial oferece uma referência completa para dominar o git e adotar as melhores práticas para o gerenciamento de código em projetos individuais e colaborativos.

Índice

1. Introdução ao Git e Controle de Versão

Objetivo:

Introduzir o conceito de controle de versão, o que é o git, e como ele facilita o desenvolvimento colaborativo de projetos. Ao final desta seção, o usuário terá uma visão geral do git, sua importância no fluxo de trabalho de desenvolvimento e os primeiros passos para instalação e configuração.

Conteúdo:

1.1 O que é o Git e Controle de Versão

O git é um sistema de controle de versão distribuído, criado para gerenciar o histórico de alterações de projetos de forma eficiente e confiável. Ele permite que múltiplas pessoas trabalhem simultaneamente em um mesmo projeto, possibilitando a colaboração e o controle sobre o que cada pessoa modifica no código.

Vantagens do Git:
  • Distribuído: Cada usuário possui uma cópia completa do histórico do projeto.
  • Rápido e Eficiente: Realiza operações como commit, branch e merge de maneira rápida.
  • Segurança e Rastreabilidade: Garante a integridade dos dados e permite rastrear todas as mudanças.
  • Colaboração em Equipe: Permite que desenvolvedores trabalhem em paralelo e depois combinem suas mudanças.
1.2 Controle de Versão Distribuído e Benefícios

No controle de versão distribuído, cada usuário trabalha com uma cópia independente do repositório, ao contrário do controle centralizado, onde o repositório é central e todos devem acessar uma mesma fonte. Isso significa que as alterações são feitas localmente e depois enviadas para o repositório remoto, permitindo flexibilidade e segurança no fluxo de trabalho.

1.3 Instalando o Git

Para começar a usar o git, ele precisa estar instalado em sua máquina. Siga os passos para instalação conforme o seu sistema operacional.

Instalação em Diferentes Sistemas:
  1. Windows:
    • Baixe o instalador a partir do site oficial: https://git-scm.com.
    • Execute o instalador e siga as instruções.
    • Após a instalação, você pode usar o git através do terminal Git Bash.
  2. Linux:
    • Use o gerenciador de pacotes da sua distribuição:
      • Ubuntu/Debian: sudo apt install git
      • Fedora: sudo dnf install git
      • Arch: sudo pacman -S git
  3. macOS:
    • Instale o git via Homebrew: brew install git.
1.4 Configuração Inicial do Git

Antes de iniciar o uso, configure o nome de usuário e o e-mail, pois essas informações serão associadas aos seus commits. Esse passo é necessário para que as pessoas saibam quem fez as mudanças.

1
2
3
4
5

# Configuração de nome de usuário
git config --global user.name "Seu Nome"

# Configuração de e-mail
git config --global user.email "seuemail@exemplo.com"
Outras Configurações Úteis

  • Editor padrão: Define o editor de texto padrão para mensagens de commit e outras interações.

    1

    git config --global core.editor "nome_do_editor"

  • Checar as configurações atuais:

    1

    git config --list

Essa configuração pode ser feita de forma global (para todos os repositórios) ou de forma local (para um repositório específico). Para uma configuração local, basta executar o comando sem a flag --global.

Resumo em Tabela:
Comando Função
git config --global user.name "Nome" Define o nome de usuário globalmente.
git config --global user.email "Email" Define o e-mail do usuário globalmente.
git config --global core.editor "Editor" Define o editor padrão do Git.
git config --list Lista todas as configurações do Git.

Conclusão da Seção

Com o git instalado e configurado, você está pronto para começar a gerenciar projetos. No controle de versão, o git ajudará a manter o histórico de alterações, rastrear mudanças feitas e facilitar a colaboração. Na próxima seção, vamos explorar os conceitos básicos para entender melhor como o git funciona internamente e seus principais componentes.

2. Conceitos Fundamentais do Git

Objetivo:

Introduzir os principais conceitos e termos do git para que o usuário entenda o fluxo de trabalho e saiba como o git organiza e controla o código. Ao final, o usuário terá uma compreensão dos componentes fundamentais, incluindo repositórios, commits, branches, staging area, entre outros.

Conteúdo:

2.1 Principais Conceitos e Termos

Para entender o funcionamento do git, é essencial conhecer alguns dos seus termos fundamentais:

  1. Repositório (Repository): É o ambiente onde o código-fonte e seu histórico de alterações são armazenados. No git, você pode ter repositórios locais (em sua máquina) e remotos (em servidores online, como GitHub ou GitLab).

  2. Commit: Um commit é um ponto no histórico do projeto que salva as alterações realizadas. Ele representa uma “foto” do estado do projeto em um dado momento, junto com uma mensagem descritiva. Cada commit é identificado por um hash único.

  3. Branch: Uma branch (ou “ramificação”) é uma linha independente de desenvolvimento. Branches permitem que você trabalhe em funcionalidades ou correções separadamente sem interferir no trabalho da branch principal (geralmente chamada main ou master).

  4. Staging Area: Também chamada de “index”, é um espaço temporário onde as alterações ficam antes de serem confirmadas (ou “comitadas”). O comando git add coloca alterações na staging area.

  5. Working Directory (Diretório de Trabalho): É o diretório onde você edita seus arquivos. O git monitora as mudanças que você faz no diretório de trabalho para poder versioná-las.

2.2 O Fluxo de Trabalho Básico no Git

O fluxo de trabalho no git é essencial para organizar o desenvolvimento. Normalmente, o fluxo de trabalho envolve os seguintes passos:

  1. Modificações no código:
    • O usuário faz alterações nos arquivos no working directory.
  2. Adicionar à Staging Area:
    • Com o comando git add, as mudanças são selecionadas para a próxima confirmação (commit).
  3. Commit:
    • Com git commit, o git grava um snapshot do estado atual dos arquivos que estavam na staging area.
  4. Push (para repositórios remotos):
    • Caso esteja usando um repositório remoto, após realizar o commit localmente, você pode enviar as mudanças com git push.

O gráfico abaixo ilustra o fluxo de trabalho básico no git:

1

Working Directory --> Staging Area --> Commit (Local Repo) --> Push (Remote Repo)
2.3 Comandos Básicos para Controle de Versão

Esses comandos cobrem as operações principais que você usará frequentemente ao trabalhar com git.

Comando Função
git init Inicializa um novo repositório git no diretório atual.
git add <arquivo> Adiciona o arquivo especificado à staging area.
git add . Adiciona todos os arquivos modificados à staging area.
git commit -m "mensagem" Cria um commit com uma mensagem descritiva.
git status Exibe o status atual do repositório e mostra quais arquivos foram modificados.
git log Exibe o histórico de commits.
2.4 Entendendo a Staging Area

A staging area funciona como uma “área de preparação” das alterações. Isso permite que você controle quais modificações deseja incluir no próximo commit, enquanto deixa outras para depois. Por exemplo:

1
2
3
4
5
6

# Editando dois arquivos: index.html e style.css
# Adicionando apenas o index.html à staging area

git add index.html

# O style.css ainda está fora da staging area, ou seja, suas alterações não serão incluídas no próximo commit.

Esse controle é útil ao dividir o trabalho em etapas, fazendo commits mais organizados e específicos.

2.5 Branches: Desenvolvimento Paralelo

Branches são fundamentais para trabalhar em funcionalidades separadas sem afetar a base principal do projeto. Cada branch é uma cópia do projeto em um estado específico, permitindo que desenvolvedores trabalhem em paralelo. Por exemplo, ao criar uma nova funcionalidade, você pode criar uma branch específica para ela e, ao finalizar, mesclar (merge) as mudanças na branch principal.

Principais comandos para branch:

Comando Função
git branch Lista todas as branches locais.
git branch <nome_da_branch> Cria uma nova branch.
git checkout <nome_da_branch> ou git switch <nome_da_branch> Muda para a branch especificada.
git merge <nome_da_branch> Mescla a branch especificada na branch atual.

Conclusão da Seção

Com os conceitos fundamentais do git, você agora entende a estrutura do controle de versão distribuído e como as operações básicas funcionam. Na próxima seção, você aprenderá a inicializar e configurar um repositório, além de clonar repositórios existentes para seu ambiente local.

3. Inicializando e Configurando um Repositório

Objetivo:

Explicar como criar um novo repositório git ou clonar um repositório existente. Esta seção também cobre as configurações globais e locais no git para customizar o ambiente de trabalho.

Conteúdo:

3.1 Criando um Repositório Local

Para iniciar o uso do git em um projeto, você precisa primeiro inicializar um repositório local. Isso transforma o diretório atual em um repositório git, começando a rastrear mudanças no código.

1
2

# Comando para inicializar um repositório git no diretório atual
git init

Após executar git init, o git cria uma pasta oculta chamada .git no diretório, onde armazena todas as informações sobre o repositório, incluindo histórico de commits, configuração e branches.

Exemplo:
  1. Crie uma pasta para seu projeto: 
    1
2

    mkdir MeuProjeto
cd MeuProjeto
  2. Inicialize o repositório: 
    1

    git init

Você verá uma mensagem confirmando a criação do repositório, e a pasta agora está pronta para começar a rastrear arquivos.

3.2 Clonando um Repositório Existente

Caso você queira trabalhar em um projeto já existente hospedado remotamente (por exemplo, no GitHub ou GitLab), você pode clonar o repositório usando o comando git clone.

1
2

# Estrutura do comando git clone
git clone <URL_do_repositório>
Exemplo:
  1. No GitHub, copie a URL do repositório desejado.
  2. Execute o comando git clone: 
    1

    git clone https://github.com/usuario/repositorio.git

Esse comando cria uma cópia completa do repositório em sua máquina, incluindo todo o histórico de commits, branches e configurações do repositório remoto.

3.3 Configurações Globais e Locais no Git

O git permite configurações tanto globais quanto locais. As configurações globais afetam todos os repositórios que você usar na máquina, enquanto as configurações locais valem apenas para o repositório em que estão definidas.

  1. Configuração Global:
    • As configurações globais se aplicam a todos os repositórios do usuário e são armazenadas em ~/.gitconfig.
  2. Configuração Local:
    • Configurações locais são específicas de um repositório e ficam armazenadas no arquivo .git/config dentro da pasta .git do repositório.
Exemplos de Configuração Global e Local:
1
2
3
4
5
6
7

# Configurações globais (nome e e-mail)
git config --global user.name "Seu Nome"
git config --global user.email "seuemail@exemplo.com"

# Configurações locais (somente para o repositório atual)
git config user.name "Nome no Repositorio Específico"
git config user.email "email@especifico.com"
3.4 Visualizando e Modificando Configurações

Para ver as configurações atuais do git, utilize o comando git config --list. Ele exibe uma lista de todas as configurações definidas, tanto globais quanto locais.

1

git config --list

Dica: Você pode editar o arquivo .gitconfig diretamente para ajustes mais avançados.

Resumo da Seção em Tabela
Comando Função
git init Inicializa um novo repositório git no diretório atual.
git clone <URL_do_repositorio> Clona um repositório remoto para o diretório local.
git config --global user.name Define o nome de usuário global.
git config --global user.email Define o e-mail de usuário global.
git config user.name Define o nome de usuário local (para o repositório atual).
git config user.email Define o e-mail de usuário local (para o repositório atual).
git config --list Lista todas as configurações atuais do git, tanto globais quanto locais.

Conclusão da Seção

Com estas instruções, você sabe como iniciar um novo repositório do zero e configurar o git para uso pessoal ou de equipe. Essas configurações garantem que todos os commits sejam identificados corretamente e que o repositório funcione de forma ideal para o seu projeto.

4. Registrando Alterações: Adicionar e Commitar

Objetivo:

Explicar como registrar mudanças no repositório git através dos comandos de adicionar (git add) e comitar (git commit). Além disso, vamos discutir como escrever mensagens de commit eficazes e visualizar o histórico de commits.

Conteúdo:

4.1 Adicionando Alterações à Staging Area

A staging area é um estágio intermediário onde as mudanças são preparadas antes de serem confirmadas (ou “comitadas”) no histórico do repositório. O comando git add é utilizado para mover arquivos modificados para a staging area.

Sintaxe Básica:
1
2
3
4
5

# Adiciona um arquivo específico à staging area
git add <nome_do_arquivo>

# Adiciona todos os arquivos modificados no diretório atual
git add .
Exemplo:

Após editar index.html e style.css, você pode adicionar ambos os arquivos de uma vez ou apenas um deles:

1
2
3
4
5

# Adiciona apenas o index.html à staging area
git add index.html

# Adiciona todos os arquivos modificados
git add .

Dica: Utilizar git add . é útil quando você deseja adicionar rapidamente todas as mudanças. Contudo, adicionar arquivos de forma seletiva permite um controle mais detalhado sobre o que vai para cada commit.

4.2 Criando Commits

Após adicionar arquivos à staging area, você pode usar o comando git commit para gravar essas mudanças no repositório. Cada commit é uma versão salva do seu projeto e inclui uma mensagem que descreve as alterações.

Sintaxe Básica:
1
2

# Cria um commit com uma mensagem descritiva
git commit -m "Mensagem do commit"
Exemplo:

Após adicionar as mudanças na staging area, faça o commit com uma mensagem que descreva o que foi feito:

1

git commit -m "Adiciona layout inicial no index.html e estilo básico em style.css"

Boas Práticas: Use mensagens claras e concisas para que outros colaboradores (e você mesmo no futuro) possam entender rapidamente o que foi alterado. Evite mensagens genéricas como “alterações” ou “atualização”.

4.3 Estrutura de Mensagens de Commit Eficazes

Escrever mensagens de commit eficazes facilita o entendimento do histórico de mudanças. Uma prática comum é usar a estrutura:

  1. Resumo: Uma breve descrição (máximo de 50 caracteres) no imperativo, por exemplo, “Corrige bug na página de login”.
  2. Descrição Detalhada (opcional): Explicação mais detalhada da mudança, especialmente útil para commits mais complexos.
1
2
3

Resumo do commit

Descrição detalhada (se necessário)
Exemplo de Mensagem de Commit:
1

git commit -m "Corrige bug na página de login" -m "Resolvido problema onde usuários não conseguiam se autenticar devido a erro no formulário."
4.4 Visualizando o Histórico de Commits

Após criar alguns commits, você pode visualizar o histórico de mudanças com o comando git log. Este comando exibe uma lista de commits, mostrando o autor, a data e a mensagem de cada commit.

1

git log
Opções Úteis para git log:
  1. Histórico simplificado: 
    1

    git log --oneline

    Exibe cada commit em uma única linha, mostrando apenas o hash e o resumo da mensagem.

  2. Histórico filtrado por autor: 
    1

    git log --author="Nome do Autor"
  3. Histórico com diferenças entre commits: 
    1

    git log -p

    Exibe as diferenças de cada commit com as versões anteriores.

Resumo da Seção em Tabela
Comando Função
git add <arquivo> Adiciona um arquivo específico à staging area.
git add . Adiciona todos os arquivos modificados à staging area.
git commit -m "mensagem" Cria um commit com a mensagem especificada.
git log Exibe o histórico completo de commits do repositório.
git log --oneline Exibe o histórico de commits em uma linha por commit (resumo).
git log -p Exibe o histórico de commits com detalhes de diferenças (diffs).

Conclusão da Seção

Nesta seção, aprendemos como registrar alterações no git através dos comandos git add e git commit, além de como visualizar o histórico de commits com git log. Estes passos formam a base do controle de versão, garantindo que todas as modificações fiquem documentadas e acessíveis.

5. Trabalhando com Branches

Objetivo:

Ensinar como criar, visualizar, e alternar entre branches no git para organizar o fluxo de trabalho. Você também aprenderá sobre as melhores práticas para o uso de branches, especialmente em projetos colaborativos.

Conteúdo:

5.1 O Que São Branches?

No git, uma branch é uma linha de desenvolvimento independente que permite trabalhar em uma nova funcionalidade ou corrigir um bug sem afetar o trabalho principal no projeto. Por padrão, todos os repositórios têm uma branch principal chamada main ou master. Ao criar novas branches, você pode experimentar e testar mudanças sem comprometer o código estável.

Vantagens do Uso de Branches:
  • Facilita o trabalho em funcionalidades e correções isoladas.
  • Permite a colaboração entre desenvolvedores, que podem trabalhar em diferentes branches simultaneamente.
  • Facilita a revisão de código ao usar branches separadas para Pull Requests (PRs).
5.2 Criando e Listando Branches

  1. Criar uma Nova Branch: Para criar uma nova branch, utilize o comando git branch <nome_da_branch>.

    1

    git branch minha-nova-branch

  2. Listar Branches Existentes: Para visualizar todas as branches locais do repositório, utilize:

    1

    git branch

    A branch ativa será indicada por um asterisco (*) ao lado do nome.

Exemplo:
1
2
3

$ git branch
* main
  minha-nova-branch
5.3 Alternando Entre Branches

Para mudar de uma branch para outra, use o comando git checkout <nome_da_branch> ou, nas versões mais recentes, git switch <nome_da_branch>.

1
2
3
4
5

# Alterna para a branch 'minha-nova-branch'
git checkout minha-nova-branch

# Alterna usando o comando git switch
git switch minha-nova-branch

Dica: Sempre certifique-se de salvar e comitar suas mudanças na branch atual antes de alternar para uma nova branch, evitando perda de alterações não rastreadas.

5.4 Criando e Alternando Para uma Nova Branch Diretamente

Para criar e mudar para uma nova branch em um único comando, use:

1

git checkout -b nova-branch

ou

1

git switch -c nova-branch
5.5 Melhor Prática: Nomeação de Branches

Ao trabalhar em equipe, siga uma convenção de nomenclatura para facilitar o entendimento do propósito de cada branch. Algumas práticas comuns incluem:

  • Para novas funcionalidades: feature/nome_da_funcionalidade
  • Para correções de bugs: bugfix/descricao_do_bug
  • Para melhorias pequenas: chore/descricao
Exemplos:
1
2
3

feature/autenticacao-de-usuario
bugfix/corrigir-erro-login
chore/atualizar-dependencias
5.6 Excluindo Branches

Após finalizar o trabalho em uma branch e mesclar as alterações (veja a próxima seção sobre git merge), você pode excluí-la:

1
2

# Exclui uma branch local
git branch -d nome_da_branch

Caso a branch não esteja mesclada com outra branch, o git impedirá a exclusão para evitar perda de dados. Para forçar a exclusão, use:

1

git branch -D nome_da_branch
Resumo da Seção em Tabela
Comando Função
git branch Lista todas as branches locais.
git branch <nome_da_branch> Cria uma nova branch com o nome especificado.
git checkout <nome_da_branch> Alterna para a branch especificada.
git switch <nome_da_branch> Alterna para a branch especificada (método moderno).
git checkout -b <nova_branch> Cria e alterna para uma nova branch.
git switch -c <nova_branch> Cria e alterna para uma nova branch (método moderno).
git branch -d <nome_da_branch> Exclui a branch especificada (se já tiver sido mesclada).
git branch -D <nome_da_branch> Força a exclusão de uma branch, mesmo que não tenha sido mesclada.

Conclusão da Seção

O uso de branches facilita o desenvolvimento paralelo e organiza melhor o fluxo de trabalho, especialmente em equipes. As branches permitem que cada desenvolvedor trabalhe em funcionalidades e correções sem interferir na branch principal, promovendo um processo de desenvolvimento mais seguro e colaborativo.

6. Mesclando Alterações com git merge e git rebase

Objetivo:

Demonstrar como mesclar alterações de diferentes branches e resolver conflitos. Essa seção abrange os comandos git merge e git rebase, com exemplos para entender quando usar cada abordagem e as práticas recomendadas.

Conteúdo:

6.1 Introdução ao Merge e Rebase

Quando você trabalha com múltiplas branches, em algum momento precisará combinar as mudanças feitas em uma branch com outra. Isso é feito com git merge ou git rebase.

  • git merge: Une duas branches, criando um commit de mesclagem (merge commit) que preserva o histórico de ambas as branches.
  • git rebase: Movimenta (ou “reaplica”) os commits de uma branch sobre outra, criando um histórico linear, sem commits de mesclagem.
6.2 Mesclando Branches com git merge

O comando git merge é usado para integrar mudanças de uma branch na branch atual.

Sintaxe Básica:
1
2

# Estando na branch principal (ex: main)
git merge <nome_da_branch>
Exemplo:
  1. Suponha que você está na branch main e deseja mesclar as alterações da branch feature/login. 
    1
2

    git checkout main
git merge feature/login
  2. O git cria um merge commit para representar a união das mudanças.
6.3 Resolvendo Conflitos de Merge

Durante o merge, se as mesmas linhas de código foram alteradas em ambas as branches, ocorrerá um conflito de merge. O git informará quais arquivos têm conflitos, e você precisará editá-los manualmente para resolver o conflito.

Passos para Resolver Conflitos:
  1. Abra o arquivo com conflito. O git marca as seções conflitantes assim: 
    1
2
3
4
5

    <<<<<<< HEAD
Conteúdo da branch atual
=======
Conteúdo da branch mesclada
>>>>>>> nome_da_branch
  2. Edite o conteúdo para resolver o conflito, mantendo as alterações corretas.
  3. Após resolver todos os conflitos, use: 
    1

    git add <arquivo_resolvido>
  4. Finalize o merge com: 
    1

    git commit
6.4 Reorganizando Commits com git rebase

O git rebase permite que você reaplique commits de uma branch sobre outra, criando um histórico linear. Ao invés de um merge commit, ele ajusta os commits existentes para que pareçam uma sequência contínua.

Sintaxe Básica:
1
2

# Estando na branch que deseja mover
git rebase <branch_destino>
Exemplo:
  1. Suponha que você está na branch feature/login e quer atualizá-la com as alterações da branch main. 
    1
2

    git checkout feature/login
git rebase main
  2. O git aplicará os commits da branch feature/login no topo dos commits de main, reorganizando o histórico.

Dica: O rebase é útil para manter um histórico limpo, mas deve ser usado com cautela em branches compartilhadas, pois altera o histórico.

6.5 Comparação entre Merge e Rebase
Comando Descrição Histórico
git merge Combina as alterações de duas branches, criando um commit de merge. Preserva o histórico completo com um commit de mesclagem.
git rebase Reaplica os commits de uma branch sobre outra, criando um histórico linear. Cria um histórico linear e mais limpo, mas altera o histórico.

Prática Recomendada: Use git merge em branches compartilhadas (ex.: main) para preservar o histórico de mudanças. Use git rebase em branches locais de desenvolvimento para manter o histórico linear antes de mesclar.

Resumo da Seção em Tabela
Comando Função
git merge <nome_da_branch> Mescla a branch especificada na branch atual.
git rebase <branch_destino> Reorganiza os commits da branch atual sobre a branch especificada, mantendo o histórico linear.
git status Mostra o status do repositório, incluindo conflitos durante o merge ou rebase.
git add <arquivo> Marca um arquivo como resolvido após um conflito.
git commit Finaliza o merge ou rebase após resolver conflitos.

Conclusão da Seção

Você agora entende as diferenças entre merge e rebase e sabe como resolver conflitos. A escolha entre merge e rebase depende do seu objetivo de manter ou limpar o histórico. Com essas ferramentas, você pode gerenciar a integração de código de maneira eficiente e organizada.

7. Trabalhando com Repositórios Remotos

Objetivo:

Explicar como conectar repositórios locais ao git remoto e utilizar comandos como git push, git pull e git fetch para enviar e sincronizar alterações. Ao final, você será capaz de configurar repositórios remotos e entender o fluxo de colaboração com outros desenvolvedores.

Conteúdo:

7.1 Adicionando um Repositório Remoto

Um repositório remoto é uma versão do seu projeto hospedada em um servidor, como GitHub, GitLab ou Bitbucket, que permite a colaboração e o backup do seu código. Para adicionar um repositório remoto ao repositório local, use o comando git remote add.

Sintaxe Básica:
1

git remote add <nome_remoto> <URL_do_repositorio>
Exemplo:
  1. Crie um repositório em uma plataforma como GitHub e copie o link do repositório.

  2. Adicione o repositório remoto ao seu projeto local:

    1

    git remote add origin https://github.com/usuario/meu-repositorio.git

    Aqui, origin é o nome padrão para o repositório remoto principal.

7.2 Enviando Alterações com git push

Após adicionar e comitar mudanças no repositório local, você pode enviá-las para o repositório remoto usando git push.

Sintaxe Básica:
1

git push <nome_remoto> <nome_da_branch>
Exemplo:

Para enviar as mudanças da branch main ao repositório remoto origin, use:

1

git push origin main

Dica: Para simplificar, você pode configurar a branch local para empurrar automaticamente para a branch remota correspondente com git push -u origin main.

7.3 Obtendo Atualizações com git pull

O comando git pull combina dois passos: ele busca (fetch) e mescla (merge) as mudanças do repositório remoto com o repositório local. É usado para atualizar a branch local com as últimas alterações feitas por outros colaboradores.

Sintaxe Básica:
1

git pull <nome_remoto> <nome_da_branch>
Exemplo:

Para atualizar a branch main local com as mudanças do repositório remoto origin, use:

1

git pull origin main

Se houver conflitos entre as alterações locais e as remotas, você precisará resolvê-los manualmente antes de concluir o pull.

7.4 Sincronizando Mudanças com git fetch

Diferente de git pull, o git fetch apenas traz as mudanças do repositório remoto para o local sem mesclá-las automaticamente. Esse comando é útil para visualizar as atualizações antes de integrá-las ao projeto.

Sintaxe Básica:
1

git fetch <nome_remoto>
Exemplo:

Para buscar atualizações de origin, use:

1

git fetch origin

Após o fetch, você pode ver as mudanças e decidir se quer mesclá-las com git merge.

7.5 Visualizando e Gerenciando Repositórios Remotos

Para listar e verificar os repositórios remotos configurados no projeto, use:

1

git remote -v

Este comando exibe os repositórios remotos, listando o nome e a URL de cada um. Isso é útil para confirmar se você está usando o repositório correto.

Exemplo de Saída:
1
2

origin  https://github.com/usuario/meu-repositorio.git (fetch)
origin  https://github.com/usuario/meu-repositorio.git (push)

Para renomear um repositório remoto, use:

1

git remote rename <nome_antigo> <nome_novo>

E para remover um repositório remoto:

1

git remote remove <nome_remoto>
Resumo da Seção em Tabela
Comando Função
git remote add <nome> <URL> Adiciona um novo repositório remoto com o nome especificado.
git push <nome_remoto> <nome_da_branch> Envia (faz push) das mudanças da branch local para o repositório remoto.
git pull <nome_remoto> <nome_da_branch> Busca e mescla as mudanças da branch remota com a branch local atual.
git fetch <nome_remoto> Busca (fetch) as mudanças do repositório remoto sem mesclar automaticamente.
git remote -v Lista os repositórios remotos configurados.
git remote rename <nome_antigo> <nome_novo> Renomeia um repositório remoto.
git remote remove <nome> Remove um repositório remoto do projeto.

Conclusão da Seção

Agora você sabe como conectar um repositório local a um repositório remoto e sincronizar as mudanças. Com esses comandos, é possível colaborar com outros desenvolvedores de maneira eficiente, mantendo o repositório local atualizado e compartilhando suas alterações.

8. Revertendo e Desfazendo Alterações

Objetivo:

Ensinar como desfazer alterações e reverter commits no git. Esta seção cobre o uso de git checkout, git restore, git reset e git revert para gerenciar e corrigir mudanças em diferentes estágios do desenvolvimento.

Conteúdo:

8.1 Comandos para Desfazer Alterações em Arquivos

Durante o desenvolvimento, é comum precisar desfazer mudanças. Dependendo de onde as mudanças estão (no working directory, na staging area, ou já comitadas), o git oferece diferentes comandos para desfazer as alterações:

8.1.1 Desfazendo Alterações no Working Directory com git restore

Se você fez mudanças em um arquivo, mas ainda não as adicionou à staging area, pode desfazê-las usando git restore.

1

git restore <nome_do_arquivo>

Este comando restaura o arquivo à última versão comitada, removendo quaisquer mudanças não rastreadas.

Exemplo:

Se você modificou index.html e quer descartar essas alterações:

1

git restore index.html
8.1.2 Desfazendo Alterações na Staging Area com git restore --staged

Se você já adicionou mudanças à staging area com git add, mas ainda não fez o commit, use git restore --staged para removê-las da staging area, mantendo as alterações no working directory.

1

git restore --staged <nome_do_arquivo>
Exemplo:

Para remover style.css da staging area:

1

git restore --staged style.css
8.2 Desfazendo Commits com git reset e git revert

Para desfazer mudanças que já foram comitadas, você pode usar git reset ou git revert, dependendo do objetivo:

8.2.1 Revertendo Commits com git reset

O git reset permite que você “volte” o estado do repositório para um commit anterior, removendo os commits subsequentes do histórico. Esse comando é poderoso e oferece três opções principais:

  1. --soft: Remove os commits, mas mantém as mudanças na staging area.
  2. --mixed (padrão): Remove os commits e mantém as mudanças no working directory, mas fora da staging area.
  3. --hard: Remove os commits e descarta as mudanças, sem possibilidade de recuperação.
1
2
3

git reset --soft <hash_do_commit>
git reset --mixed <hash_do_commit>
git reset --hard <hash_do_commit>

Atenção: Usar --hard é arriscado, pois remove as alterações de forma definitiva. Utilize-o apenas se tiver certeza de que deseja descartar as mudanças.

Exemplo:

Para redefinir o repositório ao estado de um commit anterior (preservando as alterações no working directory):

1

git reset --mixed <hash_do_commit>
8.2.2 Revertendo Commits com git revert

Diferente do git reset, o git revert cria um novo commit que “desfaz” as alterações de um commit anterior, mantendo o histórico de forma segura. Esse comando é ideal para reverter mudanças em repositórios compartilhados.

1

git revert <hash_do_commit>
Exemplo:

Para desfazer um commit específico:

1

git revert <hash_do_commit>

Dica: Use git revert em repositórios compartilhados, especialmente quando precisa desfazer mudanças sem reescrever o histórico.

8.3 Recuperando Arquivos Deletados com git checkout

Se você removeu um arquivo do working directory, mas ainda não comitou a remoção, pode recuperá-lo com git checkout.

1

git checkout -- <nome_do_arquivo>
Exemplo:

Para restaurar README.md que foi acidentalmente deletado:

1

git checkout -- README.md
Resumo da Seção em Tabela
Comando Função
git restore <arquivo> Desfaz alterações não comitadas no working directory (descarta mudanças).
git restore --staged <arquivo> Remove o arquivo da staging area, mantendo as alterações no working directory.
git reset --soft <hash_do_commit> Remove commits, mantendo as mudanças na staging area.
git reset --mixed <hash_do_commit> Remove commits, mantendo as mudanças no working directory, fora da staging area.
git reset --hard <hash_do_commit> Remove commits e descarta todas as mudanças, irreversível.
git revert <hash_do_commit> Reverte um commit criando um novo commit de reversão.
git checkout -- <arquivo> Restaura um arquivo deletado ou modifica-o para a última versão comitada.

Conclusão da Seção

Você aprendeu como desfazer alterações em diferentes estágios do repositório git e quando usar cada comando (restore, reset e revert). Esses comandos ajudam a corrigir erros e gerenciar alterações de forma segura, mantendo o controle e integridade do projeto.

9. Stash: Salvando Alterações Temporariamente

Objetivo:

Explicar como usar o git stash para salvar alterações temporariamente sem fazer um commit. Esta seção cobre os comandos git stash, git stash pop, git stash list, entre outros, mostrando como usar o stash durante trocas de branch e gerenciamento de mudanças temporárias.

Conteúdo:

9.1 O Que é o git stash?

O comando git stash permite salvar o estado atual do working directory e da staging area de forma temporária, permitindo que você alterne para outra branch ou resolva outra tarefa sem precisar fazer um commit das mudanças inacabadas.

Exemplo de uso: Imagine que você está no meio de uma nova funcionalidade e precisa corrigir um bug em outra branch. Com o git stash, você salva suas alterações atuais, alterna para a branch do bug, resolve-o, e depois retorna à sua funcionalidade sem perder o progresso.

9.2 Salvando Alterações Temporárias com git stash

Para salvar as mudanças, utilize o comando git stash. Isso cria uma cópia do estado atual e limpa as alterações do working directory e da staging area, deixando o repositório como estava no último commit.

1

git stash
Exemplo:
1
2

# Suponha que você editou index.html e style.css
git stash

Após usar git stash, o repositório retorna ao último commit, e suas alterações são armazenadas em uma lista de stashes.

Dica: Use git stash save "descrição" para adicionar uma descrição ao stash, facilitando o gerenciamento de múltiplos stashes.

9.3 Visualizando Stashes com git stash list

Para ver uma lista de todas as mudanças salvas com git stash, use:

1

git stash list
Exemplo de Saída:
1
2

stash@{0}: On main: alteração temporária no layout
stash@{1}: On main: ajustando estilos para o header

Cada entrada no stash possui um identificador stash@{n}, onde n representa a posição do stash na lista, sendo stash@{0} o stash mais recente.

9.4 Recuperando Alterações com git stash apply e git stash pop

Para restaurar as mudanças salvas no stash, você pode usar:

  1. git stash apply: Aplica o stash, mas mantém uma cópia das alterações na lista de stashes.

    1

    git stash apply stash@{0}

  2. git stash pop: Aplica o stash e remove-o da lista, útil quando você quer reaplicar o stash apenas uma vez.

    1

    git stash pop
Exemplo:

Após resolver o bug em outra branch, retorne à branch original e aplique o stash:

1
2

git checkout minha-branch
git stash pop
9.5 Excluindo Stashes com git stash drop e git stash clear

Para remover um stash específico ou limpar todos os stashes, use:

  1. Remover um stash específico: 
    1

    git stash drop stash@{n}
  2. Remover todos os stashes: 
    1

    git stash clear
Resumo da Seção em Tabela
Comando Função
git stash Salva alterações do working directory e da staging area temporariamente.
git stash save "descrição" Salva alterações com uma descrição opcional.
git stash list Exibe a lista de stashes salvos.
git stash apply stash@{n} Aplica um stash específico sem removê-lo da lista.
git stash pop Aplica o stash mais recente e o remove da lista.
git stash drop stash@{n} Remove um stash específico da lista.
git stash clear Remove todos os stashes da lista.

Conclusão da Seção

O git stash é uma ferramenta essencial para desenvolvedores que precisam gerenciar várias tarefas ou corrigir problemas de última hora sem comprometer o trabalho em andamento. Ele permite que você pause mudanças e retome-as quando necessário, otimizando a produtividade e flexibilidade no controle de versão.

10. Visualizando o Histórico e o Status do Repositório

Objetivo:

Ensinar como inspecionar o estado do repositório git, verificar mudanças no código e acessar o histórico de commits. Ao final, você saberá como usar comandos como git status, git log e git diff para monitorar o progresso do projeto e revisar mudanças.

Conteúdo:

10.1 Visualizando o Status do Repositório com git status

O comando git status exibe o estado atual do repositório, incluindo:

  • Arquivos modificados no working directory.
  • Arquivos adicionados à staging area.
  • Arquivos não rastreados.
  • Branch atual e informações sobre o repositório remoto.
1

git status
Exemplo de Saída:
1
2
3
4
5
6
7
8
9
10

On branch main
Your branch is up to date with 'origin/main'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
        modified:   index.html

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        newfile.txt

O git status fornece uma visão geral do repositório, ajudando a verificar se todas as mudanças necessárias foram adicionadas ou comitadas antes de realizar outras operações.

10.2 Visualizando o Histórico de Commits com git log

O git log exibe uma lista detalhada dos commits feitos no repositório, mostrando informações como:

  • Identificador (hash) do commit.
  • Autor e data do commit.
  • Mensagem de commit.
1

git log
Opções Úteis para git log:
  1. --oneline: Exibe o histórico de commits de forma compacta, uma linha por commit. 
    1

    git log --oneline
  2. --graph: Adiciona um gráfico de branches e merges ao log, útil para visualizar a estrutura do repositório. 
    1

    git log --graph --oneline
  3. --author: Filtra commits por autor. 
    1

    git log --author="Nome do Autor"
  4. -p: Mostra as diferenças (diffs) entre cada commit e o commit anterior. 
    1

    git log -p
Exemplo de Saída Compacta:
1
2
3

a2c4b29 Ajuste no layout do rodapé
b56e5a1 Correção de bug no formulário de login
ac3f1b9 Implementação de autenticação

Essas opções ajudam a navegar pelo histórico e a revisar alterações específicas, especialmente em projetos colaborativos.

10.3 Comparando Alterações com git diff

O comando git diff exibe as diferenças entre várias versões de arquivos, seja no working directory, na staging area ou entre commits. É uma ferramenta essencial para revisar mudanças antes de comitar ou para entender o impacto de um pull ou merge.

Sintaxe Básica:
1
2
3
4
5
6
7
8

# Comparar mudanças no working directory
git diff

# Comparar mudanças entre a staging area e o último commit
git diff --cached

# Comparar dois commits específicos
git diff <hash_do_commit_1> <hash_do_commit_2>
Exemplo:

Para ver as mudanças não comitadas entre o working directory e a staging area:

1

git diff

Dica: O git diff é especialmente útil para revisões de código antes de finalizar um commit, ajudando a garantir que apenas as mudanças desejadas sejam incluídas.

10.4 Visualizando o Histórico de um Arquivo Específico

Para acompanhar o histórico de alterações de um arquivo específico, use:

1

git log -- <nome_do_arquivo>

Esse comando exibe os commits onde o arquivo foi modificado, facilitando a revisão das mudanças feitas ao longo do tempo.

Exemplo:
1

git log -- index.html
Resumo da Seção em Tabela
Comando Função
git status Exibe o status atual do repositório (arquivos modificados, rastreados e não rastreados).
git log Mostra o histórico completo de commits do repositório.
git log --oneline Exibe o histórico de commits em formato compacto.
git log --graph --oneline Exibe o histórico de commits com um gráfico de branches.
git diff Exibe as diferenças entre o working directory e a staging area.
git diff --cached Exibe as diferenças entre a staging area e o último commit.
git log -- <nome_do_arquivo> Exibe o histórico de commits de um arquivo específico.

Conclusão da Seção

Nesta seção, você aprendeu a inspecionar o estado do repositório com git status, a revisar o histórico de commits com git log, e a comparar mudanças com git diff. Esses comandos são essenciais para o controle de versão, permitindo entender e revisar o progresso do projeto em qualquer ponto do desenvolvimento.

11. Git Tags: Criando e Gerenciando Versões

Objetivo:

Apresentar o uso de tags no git para marcar pontos importantes no histórico de desenvolvimento, como lançamentos de versões. Esta seção explica a diferença entre tags leves e anotadas, e ensina como criar, listar, e remover tags.

Conteúdo:

11.1 O Que São Tags no Git?

No git, as tags são usadas para marcar pontos específicos no histórico do repositório, geralmente para indicar versões de lançamento. Elas são úteis para referência, permitindo que você acesse facilmente um commit específico marcado como uma versão estável ou importante.

Existem dois tipos principais de tags:

  1. Tags Leves (Lightweight tags): São como marcadores simples de um commit específico, sem metadados extras.
  2. Tags Anotadas (Annotated tags): Armazenam informações adicionais, como mensagem, data e autor, tornando-as ideais para versões formais.
11.2 Criando Tags
Tags Leves

Para criar uma tag leve, basta indicar o nome da tag e o commit a que ela se refere (ou deixar vazio para marcar o commit atual):

1

git tag <nome_da_tag>
Exemplo:
1

git tag v1.0

Este comando cria uma tag v1.0 para o commit atual. Tags leves são rápidas de criar, mas não incluem informações adicionais.

Tags Anotadas

As tags anotadas contêm uma mensagem e outras informações. Para criar uma tag anotada, use -a seguido pelo nome da tag e -m para adicionar uma mensagem.

1

git tag -a <nome_da_tag> -m "Mensagem da tag"
Exemplo:
1

git tag -a v1.0 -m "Lançamento da versão 1.0 com novas funcionalidades"

As tags anotadas são recomendadas para marcações de versão, pois armazenam informações detalhadas, úteis para referência futura.

11.3 Listando Tags

Para visualizar todas as tags criadas no repositório, use:

1

git tag

Para exibir informações detalhadas de uma tag anotada específica, use:

1

git show <nome_da_tag>
Exemplo:
1

git show v1.0

Esse comando exibe o commit marcado pela tag v1.0 e as informações adicionais (mensagem, data e autor, no caso de uma tag anotada).

11.4 Compartilhando Tags com o Repositório Remoto

Por padrão, as tags não são enviadas para o repositório remoto quando você usa git push. Para compartilhar as tags, você pode enviar uma tag específica ou todas as tags de uma vez.

  1. Enviar uma tag específica: 
    1

    git push origin <nome_da_tag>
  2. Enviar todas as tags: 
    1

    git push origin --tags
Exemplo:

Para enviar a tag v1.0 para o repositório remoto:

1

git push origin v1.0
11.5 Removendo Tags

Se você precisar remover uma tag, use o comando -d para deletá-la localmente. Em seguida, exclua-a do repositório remoto se ela já tiver sido enviada.

  1. Remover uma tag local: 
    1

    git tag -d <nome_da_tag>
  2. Remover uma tag do repositório remoto: 
    1

    git push origin --delete <nome_da_tag>
Exemplo:

Para remover a tag v1.0 localmente e remotamente:

1
2

git tag -d v1.0
git push origin --delete v1.0
Resumo da Seção em Tabela
Comando Função
git tag <nome_da_tag> Cria uma tag leve para o commit atual.
git tag -a <nome_da_tag> -m "mensagem" Cria uma tag anotada com uma mensagem.
git tag Lista todas as tags no repositório.
git show <nome_da_tag> Exibe detalhes de uma tag específica (anotada).
git push origin <nome_da_tag> Envia uma tag específica para o repositório remoto.
git push origin --tags Envia todas as tags locais para o repositório remoto.
git tag -d <nome_da_tag> Remove uma tag local.
git push origin --delete <nome_da_tag> Remove uma tag do repositório remoto.

Conclusão da Seção

As tags no git são uma ferramenta importante para marcar versões e marcos importantes no histórico do repositório, facilitando o acesso a lançamentos específicos. Ao dominar o uso de tags leves e anotadas, você pode gerenciar versões de forma mais organizada e eficiente.

12. Colaboração com GitHub/GitLab e Pull Requests (PRs)

Objetivo:

Demonstrar como colaborar com outros desenvolvedores em plataformas como GitHub e GitLab, utilizando git para criar e revisar pull requests (PRs). Ao final, você saberá como fazer contribuições, submeter alterações para revisão e colaborar no fluxo de revisão de código.

Conteúdo:

12.1 O Que é um Pull Request (PR)?

Um pull request (PR) é uma solicitação para mesclar alterações de uma branch (geralmente uma branch de desenvolvimento) em outra branch principal, como main ou master. Os PRs permitem que os desenvolvedores revisem e discutam as mudanças antes de integrá-las, promovendo a colaboração e garantindo a qualidade do código.

  • No GitHub, os PRs são usados principalmente para colaboração em repositórios públicos e privados.
  • No GitLab, o processo é conhecido como Merge Request (MR), mas a funcionalidade é semelhante.
12.2 Fluxo de Trabalho para Pull Requests

Para colaborar com um projeto usando PRs, siga este fluxo de trabalho básico:

  1. Crie uma branch para a sua funcionalidade ou correção: 
    1

    git checkout -b feature/nova-funcionalidade
  2. Desenvolva e faça commits das suas alterações: 
    1
2

    git add .
git commit -m "Implementa nova funcionalidade"
  3. Envie a branch para o repositório remoto: 
    1

    git push origin feature/nova-funcionalidade
  4. Abra um Pull Request no GitHub/GitLab:
    • Acesse o repositório no GitHub ou GitLab.
    • Você verá a opção de abrir um PR com base na branch que acabou de enviar.
    • Adicione uma descrição clara sobre o que a PR modifica e qualquer detalhe que facilite a revisão.
  5. Revisão e Aprovação:
    • Outros desenvolvedores podem revisar o código, fazer comentários e sugerir mudanças.
    • Realize quaisquer ajustes necessários, fazendo novos commits na branch. As novas mudanças serão refletidas automaticamente no PR.
  6. Merge da PR:
    • Uma vez aprovada, o PR pode ser mesclado (merge) na branch principal.
    • Após a mesclagem, você pode excluir a branch de desenvolvimento, se necessário.
12.3 Sincronizando Alterações: Mantendo Sua Branch Atualizada

Durante o desenvolvimento, a branch principal (main ou master) pode receber atualizações de outros colaboradores. Para manter sua branch atualizada com a branch principal, faça o seguinte:

  1. Obtenha as atualizações mais recentes: 
    1
2

    git checkout main
git pull origin main
  2. Mescle a branch principal na sua branch de desenvolvimento: 
    1
2

    git checkout feature/nova-funcionalidade
git merge main

Dica: Como alternativa ao merge, você pode usar git rebase main para aplicar suas alterações no topo dos novos commits da branch principal. Isso cria um histórico linear, mas certifique-se de que está trabalhando em uma branch que não foi compartilhada.

12.4 Fazendo Revisões em Pull Requests

Ao revisar PRs de outros desenvolvedores, você pode:

  • Comentar linhas específicas para dar feedback sobre o código.
  • Solicitar mudanças se algo precisar ser corrigido ou melhorado.
  • Aprovar o PR se o código estiver pronto para ser mesclado.

No GitHub e GitLab, cada comentário pode iniciar uma conversa sobre uma linha de código específica, promovendo uma revisão detalhada e colaborativa.

12.5 Boas Práticas para Pull Requests

  1. Use Nomes de Branches Descritivos: Nomeie suas branches de forma que reflitam a funcionalidade ou a correção de bug (feature/login, bugfix/erro-de-conexao, etc.).

  2. Escreva Descrições Claras nos PRs: Explique o que o PR modifica, quais problemas resolve e se há alguma dependência ou teste necessário.

  3. Faça Commits Pequenos e Descritivos: Isso facilita a revisão e o entendimento das mudanças.

  4. Atualize a Branch Antes de Abrir o PR: Sincronize com a branch principal para evitar conflitos de merge.

  5. Revise o Código Antes de Mesclar: Tenha uma política de revisão clara para garantir a qualidade e evitar bugs na branch principal.

Resumo da Seção em Tabela
Etapa Ação
Criação da branch git checkout -b feature/nova-funcionalidade
Commit de mudanças git add . seguido de git commit -m "mensagem"
Push da branch para o repositório remoto git push origin feature/nova-funcionalidade
Abrir Pull Request Feito via GitHub/GitLab (inicia revisão de código).
Sincronizar com a branch principal git checkout main, git pull origin main, git checkout feature/nova-funcionalidade, git merge main
Aprovação e Mesclagem da PR Revisão e aprovação no GitHub/GitLab, seguida do merge.

Conclusão da Seção

Agora você está apto a colaborar em projetos git usando Pull Requests, uma prática essencial para trabalho em equipe. Os PRs promovem um processo de desenvolvimento estruturado e colaborativo, permitindo revisões de código e controle de qualidade antes de cada mesclagem.

13. Git Aliases e Configurações Personalizadas

Objetivo:

Ensinar como personalizar o uso do git com aliases para comandos comuns e configurações avançadas. Ao final, você saberá como configurar atalhos para comandos frequentes e ajustar a interface do git para melhor usabilidade.

Conteúdo:

13.1 Git Aliases: Criando Atalhos para Comandos Comuns

Aliases no git são atalhos que simplificam o uso de comandos longos ou frequentes, tornando seu fluxo de trabalho mais eficiente. Você pode configurar aliases usando o comando git config.

Exemplos de Aliases Úteis:
  1. Alias para git status: 
    1

    git config --global alias.st status
  2. Alias para git commit -m: 
    1

    git config --global alias.ci "commit -m"
  3. Alias para git log --oneline --graph --all: 
    1

    git config --global alias.lg "log --oneline --graph --all"
  4. Alias para git checkout: 
    1

    git config --global alias.co checkout

Agora, em vez de digitar o comando completo, você pode usar o alias. Por exemplo, git st em vez de git status.

Dica: Adapte os aliases conforme suas necessidades. Esses atalhos são especialmente úteis para comandos que você usa com frequência.

13.2 Visualizando e Editando Aliases

Para listar todas as configurações e aliases criados, use:

1

git config --list

Para remover um alias, utilize o mesmo comando de criação, substituindo o valor do alias por uma string vazia:

1

git config --global --unset alias.st
13.3 Configurações de Interface e Exibição

Além dos aliases, o git permite personalizar a interface para tornar o uso mais intuitivo e organizado. Algumas opções incluem customizar o editor padrão, a exibição de cores e o comportamento dos comandos.

Editor Padrão para Mensagens de Commit

Por padrão, o git utiliza o editor de texto padrão do sistema para mensagens de commit. Para configurar um editor de sua preferência (como nano, vim ou code para o VS Code), use:

1

git config --global core.editor "code --wait"
Ativando Cores no Terminal

O git pode exibir cores no terminal para diferenciar seções de mensagens e status de arquivos, facilitando a leitura. Para ativar as cores, use:

1

git config --global color.ui auto
13.4 Configurações de Conveniência para Colaboração

  1. Ignorar automaticamente arquivos específicos: Adicione arquivos ou diretórios ao .gitignore para evitar que sejam rastreados.

  2. Configurar o comportamento de pull com rebase: Por padrão, o git pull realiza um merge. Caso prefira que git pull sempre use rebase para manter um histórico linear, configure-o assim:

    1

    git config --global pull.rebase true

  3. Autocorreção de Comandos: Para habilitar a correção automática de pequenos erros de digitação, use:

    1

    git config --global help.autocorrect 1

    O valor 1 indica que o git tentará corrigir erros automaticamente.

13.5 Usando o Arquivo .gitconfig para Gerenciar Configurações

As configurações globais do git são armazenadas no arquivo ~/.gitconfig. Esse arquivo pode ser editado diretamente para adicionar ou remover aliases e ajustar configurações. A estrutura do .gitconfig é organizada, o que facilita a leitura e a modificação das configurações.

Exemplo de Estrutura do .gitconfig:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

[user]
    name = Seu Nome
    email = seuemail@exemplo.com

[alias]
    st = status
    co = checkout
    ci = commit -m
    lg = log --oneline --graph --all

[core]
    editor = code --wait
    autocrlf = input

[color]
    ui = auto

Dica: Edite o .gitconfig com cuidado para não alterar sintaxes importantes. Esse arquivo é uma maneira prática de gerenciar várias configurações em um só lugar.

Resumo da Seção em Tabela
Comando Função
git config --global alias.<alias> "<comando>" Cria um alias para um comando git
git config --global --unset alias.<alias> Remove um alias criado
git config --global core.editor "<editor>" Define o editor de texto padrão para mensagens de commit
git config --global color.ui auto Habilita cores no terminal
git config --global pull.rebase true Configura o git pull para usar rebase em vez de merge
git config --global help.autocorrect 1 Ativa a autocorreção de comandos digitados incorretamente

Conclusão da Seção

Ao criar aliases e ajustar configurações, você pode personalizar o git para seu fluxo de trabalho, economizando tempo e simplificando o uso dos comandos. As configurações no .gitconfig permitem que você ajuste o comportamento do git conforme suas necessidades, tornando a experiência mais intuitiva e eficiente.

14. Recuperando e Aplicando Patches com git apply e git am

Objetivo:

Explicar o uso de patches no git para aplicar mudanças específicas de um commit ou arquivo de forma isolada. Esta seção cobre os comandos git apply e git am, ensinando como criar, exportar e aplicar patches para versionamento e colaboração.

Conteúdo:

14.1 O Que é um Patch no Git?

Um patch é um arquivo que contém as diferenças entre duas versões de código, geralmente usado para compartilhar mudanças sem precisar do repositório completo. No git, patches permitem aplicar alterações específicas diretamente em um projeto, facilitando o compartilhamento de atualizações e correções de bugs.

14.2 Criando um Patch a Partir de Um Commit

Para criar um patch com base em um commit específico, você pode usar o comando git format-patch. Este comando gera um arquivo .patch ou .diff que representa as mudanças feitas em um commit.

Sintaxe Básica:
1

git format-patch -1 <hash_do_commit>
Exemplo:

Para criar um patch do commit mais recente:

1

git format-patch -1 HEAD

Este comando cria um arquivo .patch no diretório atual com o nome do commit, pronto para ser compartilhado e aplicado em outro repositório.

14.3 Aplicando Patches com git apply

Para aplicar as mudanças contidas em um patch sem adicionar metadados de commit, use o comando git apply. Este comando aplica o conteúdo do patch diretamente ao working directory e à staging area, permitindo revisão e edição antes do commit final.

1

git apply <arquivo.patch>
Exemplo:

Para aplicar um patch chamado 0001-Correção-bug.patch:

1

git apply 0001-Correção-bug.patch

Após aplicar o patch, as mudanças estarão no working directory para revisão. Com isso, você pode ajustar o código e fazer o commit normalmente.

14.4 Aplicando Patches com git am para Importar Commits

O comando git am permite aplicar patches como commits, preservando as informações do autor, data e mensagem. Isso é especialmente útil para importar contribuições de outros desenvolvedores mantendo a autoria original.

Sintaxe Básica:
1

git am < arquivo.patch
Exemplo:

Para aplicar o patch 0001-Correção-bug.patch como um commit:

1

git am < 0001-Correção-bug.patch

Após o comando, o git cria um novo commit com as alterações e a mensagem original do patch.

14.5 Lidando com Conflitos ao Aplicar Patches

Assim como nos merges, ao aplicar um patch podem surgir conflitos caso o conteúdo do patch entre em conflito com o código atual. O git notificará o conflito e você poderá resolvê-lo manualmente.

  1. Conflito ao Aplicar com git apply:
    • Use git status para ver os arquivos conflitantes.
    • Edite os arquivos para resolver os conflitos.
    • Após resolver, adicione as mudanças e faça o commit.
  2. Conflito ao Aplicar com git am:
    • O git pausa o processo de aplicação e exibe o conflito.
    • Resolva o conflito manualmente, adicione as mudanças e use git am --continue para prosseguir.
    1
2

    git add <arquivo_resolvido>
git am --continue
14.6 Exportando e Compartilhando Patches

Após criar um patch com git format-patch, você pode compartilhá-lo com outros desenvolvedores para que eles apliquem a mudança. Basta enviar o arquivo .patch ou .diff gerado. Esse método é útil em colaboração externa ou quando o acesso ao repositório remoto não é permitido.

Resumo da Seção em Tabela
Comando Função
git format-patch -1 <commit> Cria um arquivo de patch a partir de um commit específico.
git apply <arquivo.patch> Aplica as mudanças do patch ao working directory, sem criar um commit.
git am < arquivo.patch Aplica o patch como um commit, preservando autor e mensagem.
git am --continue Continua aplicando o patch após resolver um conflito.

Conclusão da Seção

O uso de patches com git apply e git am permite maior flexibilidade ao compartilhar e aplicar mudanças, especialmente em situações onde o acesso direto ao repositório não é viável. Esta abordagem é útil para colaboração, correção de bugs, e contribuições em repositórios externos.

15. Casos de Uso Avançados e Melhores Práticas

Objetivo:

Apresentar práticas avançadas e recomendadas para um fluxo de trabalho organizado no git. Esta seção cobre comandos e técnicas avançadas, como git cherry-pick, git squash, e git bisect, e aborda dicas para manter um histórico limpo e eficiente.

Conteúdo:

15.1 Selecionando Commits Específicos com git cherry-pick

O comando git cherry-pick permite aplicar um commit específico de uma branch em outra, sem a necessidade de mesclar todo o histórico. Esse comando é útil para corrigir um bug em outra branch ou trazer uma funcionalidade específica para outra linha de desenvolvimento.

Sintaxe Básica:
1

git cherry-pick <hash_do_commit>
Exemplo:

Suponha que você tenha corrigido um bug na branch feature/login e queira aplicar essa correção na branch main:

  1. Identifique o hash do commit com git log.
  2. Execute: 
    1
2

    git checkout main
git cherry-pick <hash_do_commit>

O git aplicará o commit na branch main, mantendo o histórico das mudanças originais.

15.2 Limpando o Histórico de Commits com git rebase -i (Interactive Rebase)

O interactive rebase (git rebase -i) permite que você edite, combine (squash), reordene ou remova commits, facilitando a limpeza do histórico antes de um merge. Essa prática é especialmente útil para preparar uma branch antes de enviá-la para revisão.

Sintaxe Básica:
1

git rebase -i <commit_base>

Ao executar esse comando, você verá uma lista de commits em seu editor de texto. Cada commit pode ser marcado para diferentes ações, como pick (manter), squash (combinar) ou edit (modificar).

Exemplo de Uso para Squash:
  1. Suponha que você tenha feito múltiplos commits pequenos em uma branch (commit 1, commit 2, etc.).
  2. Execute o interactive rebase para combinar esses commits em um só. 
    1

    git rebase -i HEAD~3
  3. Marque os commits como squash ou s (exceto o primeiro), e finalize. O git combina os commits em um único, permitindo uma mensagem de commit consolidada.
15.3 Identificando Problemas com git bisect

O comando git bisect ajuda a encontrar o commit exato onde um bug foi introduzido. O git usa uma busca binária para verificar cada commit até identificar o commit que causou o problema, economizando tempo na depuração.

Fluxo de Trabalho do Git Bisect:
  1. Iniciar o bisect: 
    1

    git bisect start
  2. Marcar o commit onde o código estava funcionando: 
    1

    git bisect good <hash_do_commit_bom>
  3. Marcar o commit onde o código apresentou o problema: 
    1

    git bisect bad <hash_do_commit_com_problema>

O git agora faz uma busca binária, alternando entre commits para determinar onde o erro foi introduzido. Você marca cada commit intermediário como good ou bad até identificar o commit exato.

  1. Finalizar o bisect: 
    1

    git bisect reset

Dica: O git bisect é muito útil em grandes projetos, onde a causa de um bug pode estar em qualquer parte do histórico de commits.

15.4 Boas Práticas para um Histórico Limpo e Organização de Fluxo de Trabalho

  1. Commits Pequenos e Concisos: Evite commits grandes e genéricos. Em vez disso, faça commits frequentes e com mensagens descritivas, facilitando a revisão.

  2. Uso de Branches para Funcionalidades e Correções: Trabalhe em branches separadas para cada nova funcionalidade ou correção, mantendo a branch principal estável.

  3. Limpe a Branch Antes de um Pull Request: Antes de abrir um PR, use git rebase -i para limpar o histórico de commits, combinando commits pequenos e eliminando commits irrelevantes.

  4. Mantenha o Histórico Linear Sempre que Possível: Evite múltiplos merges ao usar rebase em branches locais antes de integrar com a branch principal. Isso mantém o histórico de commits limpo e linear.

  5. Revisão Regular de Código e Padrões: Em equipes, mantenha uma política clara de revisão de PRs, garantindo a consistência e qualidade do código.

Resumo da Seção em Tabela
Comando Função
git cherry-pick <hash_do_commit> Aplica um commit específico de uma branch em outra branch.
git rebase -i <commit_base> Inicia um rebase interativo para editar, combinar, ou reorganizar commits.
git bisect start Inicia o modo bisect para busca de commits problemáticos.
git bisect good <commit> Marca um commit como funcional durante o bisect.
git bisect bad <commit> Marca um commit como defeituoso durante o bisect.
git bisect reset Finaliza o bisect e retorna ao estado original.

Conclusão da Seção

Com as técnicas avançadas de git, como cherry-pick, rebase -i, e bisect, você pode manter um fluxo de trabalho organizado e eficiente, corrigindo problemas com precisão e mantendo um histórico limpo. Estas práticas avançadas ajudam no controle de qualidade e na colaboração em projetos complexos.

16. Problemas Comuns no Git e Como Resolver

1. Conflitos de Merge

Problema: Conflitos ocorrem quando o git não consegue mesclar automaticamente mudanças de duas branches, geralmente porque as mesmas linhas foram alteradas em ambas.

Solução:

  1. O git marcará os arquivos com conflitos, indicando as seções conflitantes com <<<<<<<, =======, e >>>>>>>.
  2. Edite os arquivos e resolva o conflito entre essas seções.
  3. Após resolver, adicione os arquivos e finalize o merge: 
    1
2

    git add <arquivo_resolvido>
git commit

2. Commits na Branch Errada

Problema: Realizar commits em uma branch diferente da pretendida.

Solução:

  1. Identifique o hash do commit indesejado com git log.
  2. Retorne o commit para a staging area com git reset HEAD~.
  3. Troque para a branch correta e faça o commit: 
    1
2
3

    git checkout minha-branch
git add .
git commit -m "Mensagem original do commit"

3. Alterações Perdidas com git reset --hard

Problema: git reset --hard descarta mudanças locais não comitadas, podendo causar perda de dados.

Solução:

  • Sem um commit anterior, a recuperação é difícil. Porém, você pode tentar usar: 
    1

    git reflog

    para localizar um commit anterior onde as mudanças ainda estavam presentes e restaurá-lo.

4. “Detached HEAD”

Problema: O estado Detached HEAD ocorre ao fazer checkout em um commit específico, em vez de uma branch. Alterações feitas nesse estado não ficam associadas a uma branch.

Solução:

  1. Para salvar as mudanças, crie uma nova branch e continue o trabalho: 
    1

    git checkout -b minha-nova-branch

5. Erro ao Tentar git pull (Falta de Rebase)

Problema: Ao realizar git pull, você pode receber uma mensagem informando que o repositório está fora de sincronia.

Solução:

  1. Configure rebase automático: 
    1

    git config pull.rebase true
  2. Ou faça o pull com rebase manualmente: 
    1

    git pull --rebase

6. Commit com Arquivo Grande ou Sensível por Acidente

Problema: Um arquivo grande ou sensível (como uma chave privada) foi acidentalmente incluído em um commit.

Solução:

  1. Remova o arquivo do repositório e faça um novo commit: 
    1
2

    git rm --cached <nome_do_arquivo>
git commit -m "Remove arquivo sensível"
  2. Para remover o arquivo de todo o histórico, use: 
    1

    git filter-branch --tree-filter 'rm -f nome_do_arquivo' HEAD
  3. Adicione o arquivo ao .gitignore para evitar novos commits indesejados.

7. Erro de Permissão ao Fazer git push

Problema: Erro de autenticação ao fazer git push para um repositório remoto.

Solução:

  • Verifique a configuração do repositório remoto com git remote -v.
  • Confirme que você tem acesso ao repositório e, se necessário, adicione uma chave SSH ao seu GitHub/GitLab ou configure as credenciais do usuário.

8. Histórico Poluído com Commits Pequenos e Irrelevantes

Problema: Commits pequenos ou de testes poluem o histórico do repositório.

Solução:

  • Use git rebase -i para combinar (squash) commits relacionados antes de um push, criando um histórico mais organizado.
  • Em repositórios locais, prefira o uso de rebase em vez de merge ao atualizar branches, para manter o histórico linear e mais limpo.

9. Commit Acidental em um Repositório Pessoal (Remover Repositório Remoto)

Problema: Um commit foi acidentalmente feito para o repositório pessoal ou errado.

Solução:

  1. Para remover um repositório remoto: 
    1

    git remote remove origin
  2. Para mudar o repositório remoto para o correto: 
    1

    git remote add origin <url_do_repositorio_correto>

10. Commit Específico Precisa Ser Revertido

Problema: Um commit problemático precisa ser desfeito.

Solução:

  • Para reverter um commit sem reescrever o histórico, use: 
    1

    git revert <hash_do_commit>

    Esse comando cria um novo commit que desfaz as alterações do commit especificado, mantendo o histórico claro e rastreável.

Conclusão da Seção

Estes são problemas comuns no uso diário do git, junto com soluções práticas para lidar com cada situação. Com estas dicas, você estará mais preparado para resolver questões frequentes e manter o fluxo de trabalho ágil e organizado.

Conclusão

Com o fim deste tutorial, você agora possui uma compreensão sólida do git, desde os fundamentos até as práticas avançadas, o que lhe permite gerenciar o histórico de versões com segurança e eficiência. Os conhecimentos adquiridos permitem que você contribua em projetos de forma colaborativa, mantenha o histórico de commits organizado e resolva problemas comuns no dia a dia do desenvolvimento.

Ao incorporar o uso do git no seu fluxo de trabalho, você adquire mais controle sobre as alterações de código e pode compartilhar seu trabalho com segurança e agilidade. A prática constante dos conceitos e comandos aqui abordados é fundamental para que o git se torne uma extensão natural do seu trabalho, melhorando a qualidade e a colaboração nos projetos.

Se precisar de referência para dúvidas futuras, lembre-se de que o git possui uma extensa documentação oficial, e este tutorial pode ser uma base útil para consultas rápidas. Com o git como aliado, você está pronto para enfrentar novos desafios de desenvolvimento com confiança e eficiência.

Git
Git
This post is licensed under CC BY 4.0 by the author.