DEV Community

Igor Melo
Igor Melo

Posted on • Updated on

Git para leigos

O Git hoje é uma ferramenta fundamental para praticamente todos os desenvolvedores.
Nesse artigo você irá entender de forma simplificada como o Git funciona, sua aplicabilidade e alguns comandos essenciais.
Não veremos ainda como utilizar GitHub pois isso geraria mais confusão para quem tá começando e não entende ainda como o Git funciona.

Todo mundo já fez algo assim

Seja algum trabalho da escola, TCC, ou mesmo algum projeto de programação, você com certeza já deve ter feito isso:

trabalho de historia.docx
trabalho de historia2.docx
trabalho de historia3.docx
trabalho de historia FINAL.docx
trabalho de historia FINAL DE VERDADE.docx
trabalho de historia FINAL AGORA EH PRA VALER.docx
trabalho de historia FINAL CORRECOES.docx
Enter fullscreen mode Exit fullscreen mode

Basicamente evitamos sobrescrever o arquivo por temos medo de alterar demais e não conseguir voltar a versão anterior.

Para isso há décadas surgiram vários sistemas de controle de versão, que são ferramentas que te ajudam a registrar versões, que são pontos no histórico de alterações em arquivos, basicamente.

O que é o Git

Eu gosto de pensar no Git como uma “máquina do tempo de arquivos”.

Histórico do Git

A figura acima é um exemplo de histórico de alterações, como se fosse uma linha do tempo.

Com essa “máquina” conseguimos ver como um arquivo estava no passado, desfazer alterações, criar “realidades alternativas” onde o mesmo arquivo pode ser alterado de formas diferentes, desfazer alterações e muito mais.

Histórico do Git com realidade alternativa

Na figura, em amarelo está o histórico principal, enquanto em azul é um histórico alternativo onde um tema está sendo desenvolvido. Quando esse tema é finalizado ele é combinado ao histórico principal.
Não se preocupe em entender esse conceito agora.

O Git se torna útil por uma série de motivos:

  • Você não precisa ficar criando cópias de arquivos para não perder suas alterações
  • O Git utiliza pouco armazenamento e é bem rápido
  • É ótimo para trabalhar com arquivos em formato texto, como código, arquivos de configuração, arquivos de projetos, etc
  • Tendo um histórico bem definido de alterações, é muito mais fácil entender o que foi alterado e reverter algo se necessário
  • Facilita o trabalho em equipe, sendo possível combinar o trabalho de múltiplas pessoas com detecção automática de conflitos

Instalando o Git

Siga as instruções de instalação para o seu sistema. Para o Windows, instale com as opções padrões.

Windows

Git - Downloading Package

Linux

Git

Mac

Git - Downloading Package

Seu primeiro projeto com Git

A melhor forma de aprender qualquer coisa é pondo em prática. Para isso vamos iniciar um projeto com Git.

Vamos criar um projeto do zero exclusivamente para treinar Git, pois assim vamos ficar mais a vontade de fazer alterações e executar comandos sem medo de perder algo de importante.

Para isso:

  1. Abra um terminal, no caso de Linux ou Mac, ou o Git Bash, no caso de Windows
  2. Digite mkdir aprendendo-git e aperte Enter para criar uma pasta
  3. Digite cd aprendendo-git e aperte Enter para entrar na pasta que criou
  4. Agora que está na pasta certa, digite git init e aperte Enter

Seu resultado deve ser algo similar a isso:

Criando um repositório git

Com o comando git init nós inicializamos um repositório na pasta oculta .git.
Um repositório é um local onde diversas informações, inclusive os registros de histórico, são guardadas.
O repositório só vai analisar os arquivos dentro dessa pasta aprendendo-git e das subpastas, exceto a .git em si.

Tome cuidado! Se você apagar a pasta .git, você perderá todo o histórico que foi registrado.

O comando git status

Este é um comando que iremos utilizar com bastante frequência, pois ele nos lista quais arquivos foram criados, alterados, apagados e essa alteração ainda não foi registrada no histórico.

Como no projeto que acabamos de criar ainda não tem nenhum arquivo, se rodarmos o comando git status, vamos ter a seguinte saída:

Saída do git status sem nenhuma alteração

Basicamente está sendo dito que não tem nenhuma alteração para registrar.

Vamos então criar um arquivo na pasta aprendendo-git utilizando o editor de sua preferência.

Agora se rodarmos git status de novo, vamos ter uma saída diferente:

Saída do git status quando tem alguma alteração

O arquivo que criei está com status untracked, que significa que o Git nunca registrou esse arquivo no histórico.

Obs.: o vermelho no arquivo não significa que algo está errado. O Git usa apenas para distinguir o status

Gravando alterações no histórico

Uma coisa importante para quem tá começando é que o Git não registra histórico por conta própria.

Se você fizer uma alteração e desfazer sem explicitamente registrar no Git, essa alteração vai ser perdida.

Para gravar uma alteração, precisamos seguir este fluxo:

Fazer alteração -> Preparar alteração -> Registrar alteração

1. Fazer alteração

Esse é o passo mais simples e já fizemos. Basta criar um arquivo dentro do projeto utilizando qualquer programa.

Alterações nesse estágio são chamadas de alterações não-preparadas (unstaged) e são representadas no Git pela cor vermelha.

2. Preparar alteração

Esse passo antes de registrar a alteração nos dá maior flexibilidade, porque podemos ter 10 arquivos alterados, mas só 3 que queremos registrar no momento.
Alterações nesse estágio são chamadas de preparadas (staged) e são representadas no Git pela cor verde.

Para preparar todas as alterações em um arquivo, basta rodar o comando git add <arquivo>.

Se olharmos o git status depois disso, vamos ver que agora o arquivo está com um status diferente e cor verde:

Status de um arquivo preparado

3. Registrar alteração

Até o momento, nenhuma alteração que fizemos foi de fato “salva” no repositório.
Para registrar nossas alterações preparadas (staged), nós vamos usar o comando git commit.

Esse comando cria um commit, que nada mais é do que um registro no histórico do Git.
A partir de agora vou passar a chamar “registro” de commit para você se acostumar com o termo.

Um commit por padrão exige uma mensagem resumindo o que essas alterações fazem e o porquê.
Podemos passar a mensagem utilizando a opção -m do comando commit, da seguinte forma:

git commit -m 'criando um exemplo'
Enter fullscreen mode Exit fullscreen mode

Erro ao fazer commit por não ter nome e email

Obtemos um erro porque não temos nome e email configurado no Git.

Todo commit no Git precisa dessas duas informações. Vamos fazer o sugerido e configurar nosso nome e email global.
Não existe nenhuma validação nisso, então eu posso botar qualquer email e nome:

# com o --global: todos os projetos irão usar essas credenciais por padrão
config --global user.email "igor@eu.com"
config --global user.name "Igor"

# sem o --global: cada projeto terá que configurar seu próprio user.email e user.name
config user.email "igor@eu.com"
config user.name "Igor"
Enter fullscreen mode Exit fullscreen mode

Agora se tentarmos de novo, irá funcionar:

Commit sendo feito depois de configurar email e senha

Pronto!
Fizemos nosso primeiro commit.

Agora vamos checar o status de novo:

Status após fazer um commit

E vamos novamente modificar o arquivo exemplo.txt e olhar o status:

Status de modified no arquivo exemplo.txt

Repare que o status dessa vez é modified, porque agora o arquivo já tem histórico no Git.

Vendo o histórico de commits e as alterações feitas

Há várias formas de fazer isso, mas para simplificar, vou usar um único comando: git log -p.

O git log lista os commits na ordem dos mais recentes para os mais antigos:

Saída do git log

Várias informações são mostradas, mas as mais importantes por agora são:

  • Autor (nome e email)
  • Data
  • Mensagem (criando um exemplo)

Para sair dessa visualização apertamos q e podemos mover na vertical com as setas ou scroll do mouse.

Se adicionarmos a opção -p, esse vai ser o resultado:

Saída do git log -p

De novo, aqui vemos várias informações sendo mostradas, mas as mais relevantes são:

  • Mensagem, para entender o contexto das alterações
  • Nome do arquivo que foi alterado, depois do +++ (ignore o a/ e o b/)
  • O texto em verde com prefixo +, que significa que aquela linha foi adicionada
  • Linhas em vermelho com prefixo - significa que foram removidas

Exemplo mais concreto

Vamos criar um projeto do zero de novo, mas dessa vez vamos fazer algo menos abstrato para você ter uma sensação de como é usar Git para um projeto real.

Vou criar um projeto em HTML, mas não é requisito saber.

1. Iniciando o projeto

Vamos sair da pasta aprendendo-git vamos criar uma nova pasta padaria e vamos entrar nela:

cd
mkdir padaria
cd padaria
Enter fullscreen mode Exit fullscreen mode

Vamos iniciar um repositório Git:

git init
Enter fullscreen mode Exit fullscreen mode

2. Primeiro commit

Agora vamos começar a criar a página principal, index.html:

<h1>Bem-vindo a Padaria Rubrum Panem</h1>
<p>
    Ipsum quo quia voluptatem quibusdam. Minima eos animi
    dignissimos consequuntur qui optio distinctio possimus.
</p>
Enter fullscreen mode Exit fullscreen mode

Quando sentirmos que já temos um básico feito, já podemos fazer nosso primeiro commit.

Primeiro adicionamos o arquivo index.html:

git add index.html
Enter fullscreen mode Exit fullscreen mode

E em seguida fazemos um commit:

git commit -m 'página principal'
Enter fullscreen mode Exit fullscreen mode

3. Commit de nova funcionalidade

Agora resolvemos criar uma página de contato, contato.html:

<h1>Contato</h1>
<ul>
  <li>Telefone: (99) 99999-9999</li>
  <li>Email: contato@padaria.com</li>
  <li>Endereço: Rua da Padaria, 123 - Osasco</li>
</ul>
Enter fullscreen mode Exit fullscreen mode

E criamos um link na index.html para a página contato.html:

...
<a href="/contato.html">Contato</a>
Enter fullscreen mode Exit fullscreen mode

Faz sentido que ambas as alterações sejam adicionadas a um mesmo commit, já que estão totalmente relacionadas. Sem a alteração do index.html o usuário não tem link para a página de contato, então vamos adicionar os dois arquivos:

git add index.html contato.html
Enter fullscreen mode Exit fullscreen mode

Podemos olhar o status para confirmar que os dois arquivos foram adicionados:

Verificando o status depois de um git add

E agora fazemos o commit:

git commit -m 'página de contato'
Enter fullscreen mode Exit fullscreen mode

4. Revendo os commits feitos

Se rodarmos o comando git log -p que aprendemos antes, o resultado será:

Saída do git log -p após o segundo commit

E rolando para baixo:

Saída do git log -p após o segundo commit

Conclusão

Com isso já podemos concluir a primeira parte, mas não se iluda, isso é apenas o começo!
Pratique bastante, pois mais para frente você vai aprender a reverter commits, combinar commits, criar branches, trabalhar com remotes como GitHub, criar pull requests, e muito mais.

Top comments (2)

Collapse
 
eduardoklosowski profile image
Eduardo Klosowski

Uma vez eu já usei o git para controlar as versões de um arquivo .odt (em vez de .docx). Não funciona tão bem quanto para código fonte, mas da até para ver os que mudou no texto de uma versão para outra. A configuração é um pouco complexa, mas é:

  • Instalar o odt2txt, muitas vezes já tem no repositório da distro.
  • Configurar ele no ~/.gitconfig:
[diff "odt2txt"]
textconv = odt2txt
Enter fullscreen mode Exit fullscreen mode
  • Configurar o repo para usar o odt2txt para mostrar as diferenças em arquivos .odt no arquivo .gitattributes:
*.odt binary diff=odt2txt
Enter fullscreen mode Exit fullscreen mode

Esse binary também faz com que o git não tente fazer o merge sozinho do arquivo e o corrompa. Não é a coisa mais simples de fazer ou entender, mas uma vez configurado funciona bem.

Collapse
 
igormelo profile image
Igor Melo

Boa! É até um disclaimer que esqueci de fazer:
lidar com arquivos binários no git tem suas limitações e complicações.
Eu botei o exemplo de arquivo Word mas não expliquei isso...