Como versionar utilizando o Git

Published in

Biblioteca dos Devs

14 min readJul 22, 2020

Atualmente, saber trabalhar em equipe é algo muito importante. No entanto, muito além das competências sociais, é importante também possuir as competências técnicas para conseguir colaborar com seus colegas de trabalho na entrega de bons projetos. Pensando nisso o Biblioteca dos Devs preparou este material para quem quer saber como versionar utilizando o Git.

Este artigo pretende apresentar os principais conceitos e comandos do Git de forma simples. O objetivo é que o leitor consiga obter conhecimento suficiente para começar a utilizar esta tecnologia e poder participar de projetos versionados com ela.

O que é versionamento?

O versionamento é o gerenciamento de versões diferentes de um documento de texto qualquer. Perceba que não precisa ser código.

O versionamento é controlado pelo o que chamamos de sistema de controle de versões. Normalmente, esses sistemas são utilizados no desenvolvimento de software para controlar as diferentes versões e histórico de desenvolvimento do código.

Principais vantagens em versionar

Controle de histórico

É possível visualizar todo o histórico de desenvolvimento e voltar para versões anteriores. Além disso, temos a possibilidade de avaliar no detalhe o que foi mudado de uma versão para outra.

Trabalho em equipe

Um sistema de versionamento permite que várias pessoas trabalhem no mesmo conjunto de arquivos (repositório) ao mesmo tempo em que evita conflitos entre as alterações. Cada membro do time de desenvolvimento tem sua “cópia” dos arquivos que ao final das alterações é colocada junto das versões alteradas dos demais.

Indo um pouco mais além, cada pessoa envolvida no projeto pode ter níveis de permissões diferentes para realizar determinadas ações.

Marcação e resgate de versões estáveis

Através de padrões de nomenclatura para as ramificações do código no versionamento, é possível identificar de forma fácil versões específicas e quais oferecem código estável e quais ainda estão sob avaliação ou desenvolvimento.

Ramificação de projeto

Esta é a base para o versionamento. A possibilidade de ter várias linhas de desenvolvimento paralelas sem que uma interfira na outra. Cada dev tem sua versão do código e pode alterá-la da forma como achar necessário sem receio de interferir no trabalho do seu time.

Segurança

Os softwares de controle de versão em geral possuem recursos para evitar invasões de agentes infecciosos nos arquivos. Somente usuários aos quais foi concedida permissão para edição do código conseguirão alterá-lo.

Confiança

Embora a finalidade das ferramentas de versionamento não seja a de oferecer um backup do código, mas sim seu histórico e fácil navegação entre versões, ele pode acabar servindo para isto também.

Normalmente os código versionados ficam em serviços hospedados na web que nos garantem que eles não serão perdidos. Assim, temos mais confiança de que nenhuma eventualidade poderá nos fazer perder o que já foi construído.

O que é Git?

Antes de entender como versionar utilizando o Git, é importante saber o que é o Git de fato.

O Git é uma ferramenta de versionamento não centralizado muito poderosa que permite que desenvolvedores colaborem entre si de forma organizada na construção de um projeto que envolva código. Se você ainda não o conhece, não tem problema, vamos a um overview dos principais conceitos envolvidos.

Termos importantes

Repositório e repositório remoto

O termo repositório se refere a um local onde são armazenados pacotes de software que podem ser recuperados e utilizados.

Utilizando o Git teremos repositórios locais, que armazenam os arquivos de um dado projeto em nossa máquina e repositórios remotos, que são versões de nossos repositórios locais hospedadas na internet ou em uma rede qualquer.

A ideia é sincronizar repositório local e remoto com frequência, possibilitando que outras pessoas tenham acesso ao nosso código.

O que são commits?

Um commit, ou o ato de “commitar”, se trata de agrupar alterações realizadas em seu código sob um contexto.

De acordo com a própria documentação do Git, podemos pensar nos commits como sendo cópias instantâneas da versão atual do nosso código (os famosos snapshots).

Quando realizamos um commit, cujo comando você verá mais a frente, o Git armazena um objeto de commit que possui um ponteiro para o snapshot da versão atual do código. Aleḿ disso, este mesmo objeto de commit armazena outro ponteiro que aponta para o commit anterior a ele, possibilitando ao Git saber a ordem em que as alterações aconteceram.

Portanto, você consegue acessar qualquer versão do código simplesmente indicando para o Git o identificador do commit desejado. Chamamos este identificador de hash.

O que são branches?

Podemos considerar as branches como diretórios que estão sempre apontando para o último commit de que possuem conhecimento.

Por exemplo:

Digamos que estamos em nossa branch master, a branch criada pelo git como padrão para o projeto. Ao criar uma nova branch chamada minha_funcionalidade, para trabalhar em alguma funcionalidade nova por exemplo, estaremos criando uma “cópia” da branch master que tem conhecimento dos mesmos commits que ela.

No entanto, a partir do momento em que alterarmos algum código na branch minha_funcionalidade e realizarmos um commit com estas alterações, ela passa a apontar para este último commit enquanto que a branch master continua apontando para o commit anterior.

A branch master neste caso, só tomará conhecimento das alterações feitas nesta outra branch caso solicitemos ao git para realizar a mescla do conteúdo da nossa nova branch com ela.

Working Directory e Staging

Chamamos de Working Directory a versão atual dos arquivos nos quais estamos trabalhamos. É de fato quase que a tradução literal do termo, nosso diretório de trabalho atual.

Staging por sua vez pode ser explicado como uma área entre o nosso diretório de trabalho e o nosso repositório local. É nele que ficam os arquivos que estamos selecionando para o nosso próximo commit por exemplo.

Exemplificando as coisas um pouco melhor com uma imagem:

O que é origin?

Origin é o nome dado por padrão ao repositório remoto ao qual nosso repositório local está vinculado.

Exemplo:

Executando o comando

git remote

Provavelmente teremos o retorno

origin

E executando

git remote show origin

Poderemos ver os detalhes do repositório remoto como seu link de acesso, as branches remotas e mais outras configurações.

Instalando o Git

Antes de versionar utilizando o Git, temos de instalá-lo, no entanto este é um processo bem simples independente do sistema operacional que esteja utilizando. No linux você precisará executar somente um comando e no Windows basta baixar o instalador e seguir o passo-a-passo.

Você pode encontrar todo o processo detalhado no link abaixo:

https://git-scm.com/book/en/v2/Getting-Started-Installing-Git

Como versionar utilizando o Git NA PRÁTICA

Abaixo listamos alguns dos principais comandos do Git. É interessante ter em mente que estes não são todos, uma vez que o Git nos oferece muitos outros, porém são os comandos que você utilizará em 99% das vezes dentro de um projeto versionado.

Outro ponto importante é que todos os comandos possuem uma infinidade de parâmetros que podem ser utilizados para alterar seu comportamento padrão. Portanto, caso precise aplicá-lo de forma mais específica, sempre procure a documentação.

Dito isso, vamos a lista dos principais comandos e a um exemplo prática de como versionar utilizando o Git.

Git Init

O comando git init inicializa o Git no diretório atual, criando a branch master e permitindo executar os demais comandos do Git.

Importante: Não é necessário executar o comando git init para “baixar” um repositório remoto para sua máquina. Este comando só é executado quando estamos iniciando um novo projeto para o qual ainda não existe um repositório remoto.

Exemplo:

No exemplo acima:

Criamos o diretório git-example
Navegamos até o novo diretório
Iniciamos o Git com o comando git init

Na última linha do terminal é possível inclusive ver que o git já criou a branch master, que está indicada em vermelho. Esta marcação da branch é feita pelo Oh My Zsh.

Para saber mais: https://git-scm.com/docs/git-init

Git Clone

O comando git clone, conforme o próprio nome diz, cria um novo diretório no local onde é executado e clona o código da branch escolhida de um repositório remoto para dentro dele.

Além disso, este comando também mapeia todas as branches do repositório no momento do clone e as mesmas podem ser visualizadas através do comando git branch — remotes.

Neste outro exemplo:

Utilizamos o comando git clone para clonar o repositório git-remote-example hospedado no GitHub;
Navegamos para o diretório criado pelo git-clone;
Listamos os arquivos do diretório e visualizamos um arquivo example.txt.

Para saber mais: https://git-scm.com/docs/git-clone

Git Add

O git add é o comando que utilizamos para preparar arquivos que devem ser adicionados ao nosso próximo commit.

Com ele é possível selecionar, entre os arquivos alterados, quais arquivos você deseja que estejam vinculados ao seu próximo commit.

As alterações selecionadas para serem adicionadas ao próximo commit com o comando git add são chamadas de staged.

Na imagem vemos que:

Um arquivo test.txt foi criado em nosso projeto;
Ao utilizar o comando git status (que veremos a seguir) o arquito test.txt apareceu como não monitorado;
Foi utilizado o comando git add test.txt para definir o novo arquivo como staged;
Ao utilizar o comando git status agora, o arquivo aparece como pronto para ser submetido no próximo commit.

Para saber mais: https://git-scm.com/docs/git-add

Git Status

Git status é o comando responsável por nos informar quais são os arquivos com alterações pendentes para serem adicionados a um commit. Os arquivos mostrados podem estar marcados ou não como staged.

Arquivos staged são arquivos já selecionados pelo usuário para fazerem parte do próximo commit que será executado. Os arquivos que não foram adicionados ao stage pelo comando git add, não serão considerados quando o usuário realizar um commit.

Para saber mais: https://git-scm.com/docs/git-status

Git Commit

Este comando é o que de fato cria os famosos commits. A ideia é criar um “checkpoint” do estado corrente do código da branch atual, adicionando uma mensagem para facilitar sua identificação.

Os arquivos vinculados a este “checkpoint” criado pelo comando git commit são somente os que foram adicionados como staged pelo comando git add.

Seguindo o exemplo do comando git add onde criamos e adicionamos o arquito test.txt como staged, agora iremos realizar o commit desta alteração.

No terminal mostrado acima, verificamos novamente o status de nossas alterações e em seguida utilizamos o comando git commit seguido do parâmetro -m para adicionar um commit com a mensagem “Cria arquivo test.txt”.

Para saber mais: https://git-scm.com/docs/git-commit

Git Log

O git log mostra o histórico de commits da branch atual. Acima de cada commit do log teremos um hash que funciona como um código identificador, além das informações de data, hora e autor do commit.

Utilizando o comando git log após realizar o commit do exemplo acima, teremos o seguinte retorno:

Perceba que temos o hash do commit (seu ID) sendo mostrado, a branch em que se encontra (master), o autor das alterações, a data em que o commit foi feito e a mensagem que adicionamos com o comando git add.

Dica:

Muitas vezes, além de verificar as mensagens, data, hora e autor, precisamos visualizar os arquivos alterados em cada um deles. Para isso podemos utilizar o comando git log seguido do seguinte parâmetro:

git log –name-only

Para saber mais: https://git-scm.com/docs/git-log

Git Push

O comando git push é responsável por “empurrar” nossas alterações para o repositório remoto. Se você estiver versionando um projeto no Github por exemplo, é o git push que irá enviar seus commits e arquivos modificados localmente para ele.

Exemplo:

Abaixo vemos um print de nosso repositório remoto, no GitHub, na branch master e que ainda não tem conhecimento do arquivo test.txt recém criado por nós no repositório local.

2. Então utilizamos o comando git push para “empurrar” nossos commits para o repositório remoto, preenchendo nosso login e senha do GitHub quando solicitado no terminal.

3. Agora, atualizando a página do nosso repositório remoto no GitHub, é possível ver o arquivo test.txt

Para saber mais: https://git-scm.com/docs/git-push

Git Pull

Git pull, ao contrário do git push, esse comando busca no repositório remoto versões do código que sejam mais atuais do que as que temos em nossa máquina e atualiza nossos arquivos.

Para exemplificar, vamos adicionar um arquivo README.md em nosso repositório remoto diretamente pelo painel do GitHub.

Preenchemos o README.md com um texto explicando o conteúdo do nosso repositório e clicamos em “Commit new file” para criar um commit em nosso repositório remoto referente as alterações que estamos realizando.

Feito isso, podemos ver que o arquivo já aparece em nosso repositório remoto.

No entanto, repare que nosso repositório local ainda não possui este arquivo.

Para que possamos ter nosso repositório local atualizado, utilizamos o comando git pull e perceba que o arquivo README.md passa a aparecer em nossa lista de arquivos.

Para saber mais: https://git-scm.com/docs/git-pull

Git Branch

O git branch por sua vez, lista, cria ou remove branches do repositório local ou remoto.

Listando branches locais

Ao executar o comando git branch em nosso terminal, veremos a lista de branches locais. No caso do nosso exemplo, será mostrada somente a branch master.

Listando branches remotas

Ao executar o comando git branch -r ou git branch –remotes, veremos a lista de branches presentes no repositório remoto. Em nosso caso teremos a branch master e a branch develop (esta branch foi criada somente no repositório remoto e portanto não existe ainda em nosso repositório local).

Criando branches locais

Para criar uma branch local, utilzamos o comanddo git branch seguido do nome da branch.

No exemplo abaixo, estamos criando uma branch chamada test a partir da branch master.

Agora, ao executar o comando git branch para listar as branches locais, teremos esse resultado:

Criando branches remotas

Não existe um comando específico para isto mas pode ser feito criando uma branch local como no exemplo acima e utilizando o comando push para que uma replica desta branch seja criada no repositório remoto.

Vamos enviar a branch test, criada no exemplo anterior para nosso repositório remoto.

No exemplo realizamos as seguintes ações:

Navegamos para nossa branch test recém criada com o comando git checkout (veremos ele mais a frente);
Utilizamos o comando git push e informamos a ele que gostaríamos de “empurrar” nossa branch test para o origin (nosso repositório remoto/GitHub).

Se acessarmos a lista de branches no GitHub, nosso repositório remoto, veremos que a branch test já aparece.

Removendo branches locais

Para remover uma branch local, utilizamos o comando git branch -d nome_da_branch conforme exemplo abaixo.

Importante: Se você tentar remover uma branch local estando nesta branch, o Git não permitirá a exclusão. O correto é navegar para outra branch (com o comando git checkout) e remover a branch desejada.

Caso tente excluir uma branch estando nela, o Git deve exibir a seguinte mensagem de erro:

Removendo branches remotas

O comando utilizado para remover branches remotas é o git push, não o git branch, seguido de alguns parâmetros especiais.

git push origin –delete nome_da_branch_remota

Em nosso exemplo:

Remover uma branch remota não remove a branch local e vice-versa.

Para saber mais: https://git-scm.com/docs/git-branch

Git Checkout

O comando git checkout tem como função primária nos permitir navegar entre branches e commits. Você pode acessar uma versão de código diferente em outra branch ou navegar para um commit de um ano atrás por exemplo.

Navegando por diferentes branches

Para acessar uma branch diferente, funciona assim:

git checkout nome_da_branch

No exemplo acima fizemos o seguinte:

Listamos os arquivos do nosso projeto que no momento estava na branch master;
Utilizamos o comando git checkout para acessar nossa branch develop;
Listamos os arquivos do projeto enquanto ele estava na branch develop.

Navegando por diferentes commits

No caso de um commit, você irá acessá-lo através de seu hash:

git checkout 883dd477c6aec3b495fe6f3e4625d775f91e2e18

O hash de um commit pode ser obtido através do comando git log conforme vimos anteriormente.

Ao executar o comando git log em nossa branch master, veremos que estes são seus últimos dois commits:

O commit mais recente foi onde criamos nosso arquivo README.md. Portanto se utilizamos o comando git checkout para acessar o commit “Cria arquivo test.txt”, devemos voltar para uma versão do projeto onde o arquivo README.md ainda não existia.

Primeiro fazemos o checkout para o commit “Cria arquivo test.txt” utilizando seu hash como parâmetro e depois listamos os arquivos do projeto para ver como isto funciona:

Veja que o arquivo README.md não aparece mais na listagem enquanto estivermos acessando esta versão do projeto.

Para saber mais: https://git-scm.com/docs/git-checkout

Git Merge

Este comando nos permite mesclar o conteúdo de uma branch em uma segunda branch.

Você se recorda de quando acessamos nossa branch develop e vimos que ela não possuía todos os arquivos existentes na branch master? Supondo que gostaríamos de atualizar a develop com o conteúdo mais recente da branch master, podemos utilizar o comando git merge para isso:

No exemplo acima:

Listamos o conteúdo da branch master e vimos que ele possui três arquivos;
Navegamos para a branch develop utilizando o comando git checkout;
Utilizamos o comando git merge passando “master” como parâmetro. Isto informa ao Git que gostaríamos de mesclar o conteúdo da branch master na branch em que estamos no momento (develop).
Listamos o conteúdo da branch develop e agora vimos que ela possui os mesmos arquivos que a branch master.

Neste momento, todas as alterações realizadas na branch master foram replicadas para a branch develop.

Para saber mais: https://git-scm.com/docs/git-merge

O fluxo como um todo

Considerando todos os comandos descritos nos tópicos anteriores, a imagem abaixo pode ilustrar muito bem como eles se relacionam e como funciona o fluxo de transferência de dados (no caso nosso código) dentro do Git.

Onde aprender mais?

Os comandos passados aqui são somente “a ponta do iceberg” e há muito mais para explorar no Git. Conforme você deve ter percebido, cada comando apresentado possui um link para a documentação oficial do Git onde você pode aprender mais sobre ele.

É na documentação também que você pode conhecer vários outros recursos e entender melhor como versionar utilizando o Git.

A documentação você encontra neste link — https://git-scm.com/docs