O que é git, como o git funciona, que ferramentas usar?

O que é o git?

Git é um recurso de versionamento de códigos, ou seja, salvamos n versões dos códigos do nosso projeto e podemos acessá-las posteriormente.

Como funciona o git?

Podemos imaginar o git como um Google Drive, DropBox, OneDrive... Basicamente nós 'subimos' nossos códigos e depois podemos 'baixar' esses mesmos códigos. O git vai criando ids por debaixo dos panos para identificar cada arquivo e cada alteração que fizemos em cada arquvio. Ou seja, cada alteração que fazemos tem seu id, nos permitindo acessar qualquer alteração feita ao longo do tempo.

Quais as vantagens do git?

Esse esquema de versionamento nos traz inúmeras vantagens, e é imprescindível que a gente aprenda git para entrarmos no mercado de trabalho como programadores juniores Principais vantagens:

• Back up de códigos para futuras consultas
• Facilita a identificação de causadores de bugs
• Permite o trabalho colaborativo de forma organizada
• Conseguimos implantar workflows facilmente

O que é um repositório?

O repositório nada mais é do que o nosso projeto. Podemos imaginá-lo como uma pasta que contém todos os arquivos e pastas que pertencem ao projeto.

Recursos do Repositório

Nós podemos criar um repositório, clonar um repositório (nosso ou de terceiros), atualizar um repositório ou excluir um repositório.

Pra que serve o repositório?

O repositório é o nosso projeto (com todas suas versões). Então, como dito no card anterior, podemos usá-lo para termos o back up do projeto, clonarmos em outras máquinas, trabalharmos de forma colaborativa e também é muito utilizado como nosso portfolio (muitos recrutadores querem ver a qualidade do nosso código, organização, nível de comentários e documentação e forma de pensarmos).

git é GitHub?

Não! git é a tecnologia de versionamento de códigos, enquanto GitHub é uma empresa que hospeda nossos repositórios nas nuvens (e oferece uma série de recursos).

Sobre o GitHub

Se não a mais, é uma das mais famosas plataformas de git. Basicamente ele hospeda nossos repositórios nas nuvens. Para isso, basta criarmos uma conta (gratuita) no site github.com. Lembre-se de que os recrutadores verão seu perfil, então preencha todas as informações e escolha um nome de usuário bacana.

Há alternativas ao GitHub?

Sim, existem várias opções no mercado, mas as mais utilizadas são o GitHub e o BitBucket. A diferença principal é a interface entre os dois, mas a forma de funcionamento é a mesma. Boa parte das empresas optam pelo BitBucket por ter a possibilidade de incluir mais repositórios privados e com menor restrição em relação ao número de usuários.

Como autenticar sua máquina com seu usuário git

Pode parecer um pouco confuso, mas seguindo esse passo a passo verá que não tem erro! Vamos usar tanto o site github.com quanto nosso terminal.

Gerar chave SSH

Basta abrirmos nosso repositório e rodarmos o seguinte comando:

ssh-keygen -t rsa -b 4096 -C "seuemail@exemplo.com"
Lembre-se de trocar o email pelo seu email cadastrado no GitHub.

Na sequência é necessário nomear a chave (pode apertar Enter, pois o nome padrão é o sugerido - id_rsa).

Em seguida o terminal pedirá que defina uma senha e então a confirme. Pode deixar a senha vazia (aperte Enter e Enter novamente para confirmar a senha vazia).

Atenção: se for configurar uma senha, nada do que digitar aparecerá no terminal, então preste bastante atenção na senha que inserir.

Confirmando a criação da chave

Vamos rodar a seguinte função abaixo para confirmarmos que a chave foi gerada. O comando deve retornar um PIN

eval $(ssh-agent -s)
se retornar um código com alguns números, é por que deu certo!

Atrelando a chave ao agente SSH

Para finalizarmos essa etapa, precisamos atrelar a chave SSH ao agente SSH. Basta digitar no terminal:

ssh-add ~/.ssh/id_rsa
receberemos uma mensagem de sucesso, com nossa fingerprint e um desenho que representa a chave gerada

Copiando a chave

Esse comando que iremos rodar agora dá a impressão que não acontece nada. Mas na realidade ele vai copiar nossa chave para a área de transferência. Quando pressionar Control + V (paste/colar), irá colar a chave gerada (veja o comando de acordo com seu OS (sistema operacional)

Windows
clip < ~/.ssh/id_rsa.pub

Mac
pbcopy < ~/.ssh/id_rsa.pub

Linux
xclip -sel clip < ~/.ssh/id_rsa.pub

Observação: caso tenha alterado o nome da chave, precisa se certificar que a chave copiada é a mesma declarada no comando.

Colando a chave no github.com

Estamos quase lá! Agora precisamos colar a chave que copiamos com o comando anterio no nosso perfil do GitHub. Basta:

• Logar no github.com com nosso usuário
• Acessar a página Configuração > Chaves SSH e GPG
• Clicar em ' Nova Chave SSH' (ou algo parecido)
• Definir um título para essa chave (importante: defina um nome que identifique a máquina a ser autenticada)
• Colar a chave (copiada com o comando anterior no terminal)
• Confirmar a criação da nova chave

Atenção: recomendamos que crie uma chave por máquina. Apesar de podermos usar uma mesma chave em diferentes máquinas, na hora de remover a autenticação (por exemplo do note antigo do trabalho), é mais fácil trabalharmos com uma por máquina, assim simplesmente excluímos a chave criada para aquele dispositivo específico.

Definindo nosso user na máquina

Agora que temos nossa máquina configurada, podemos configurar nosso usuário git nela! Há duas formas de fazermos isso: a forma global (onde nosso usuário será considerado em todo e qualquer repositório dentro de nossa máquina) ou de forma local (dentro de um repositório específico - nesse caso precisamos rodar o comando dentro da pasta do repositório).

Forma Global (toda a máquina)

git config --global user.name "Nome Completo"
estamos definindo o nome de usuário globalmente

git config --global user.email "seuemail@exemplo.com"
estamos definindo o email de usuário globalmente

Forma Local (apenas no repositório)

cd caminho/do/repositorio-na-nossa-maquina
acessando o repo onde queremos configurar o user

git config user.name "Nome Completo"
estamos definindo o nome de usuário local

git config user.email "seuemail@exemplo.com"
estamos definindo o email de usuário local

Observação: os dados precisam ser os mesmos cadastrados no seu perfil do GitHub.

Termos mais usados no git

Dentro do git, temos vários termos específicos. Com o tempo irá se familiarizar com todos esses termos. Enquanto isso, temos uma colinha!

add

O add é um comando que executamos para enviar as atualizações salvas em nosso ambiente local para stage (explicado mais adiante). Basicamente estamos dizendo 'vou querer agrupar essas alterações no próximo commit'. Fazemos isso com o comando git add *, sendo que o * na verdade deve ser subsituído por:

• . para selecionarmos todas as alterações feitas em ambiente local,
• nomedoarquivo.ext para adicionarmos apenas um arquivo específico,
• pasta/* para selecionar todos os arquivos numa pasta específica.

Exemplos completos:
git add .
git add meu-arquivo.txt
git add assets/js/*

branch

Como o git trabalha com versionamento dos arquivos, além de podermos acessar os arquivos da forma que estavam em determinada data, também conseguimos criar e acessar cópias exatas do projeto naquele momento, naquele estado. Essa cópia, essa instância é o que chamamos de branch.

Para criarmos uma branch, usamos
git checkout -b nome-da-branch

Para acessarmos uma branch, usamos
git checkout nome-da-branch

Perceba que é o -b é que indica que estamos criando uma nova branch.

commit

O commit nada mais é do que um pacote de alterações que fizemos nos arquivos e pastas. Cada commit possui um ID próprio, para que possamos localizá-lo posteriormente. Esse ID irá referenciar ao commit, que é o pacote de atualizações feitas naquele projeto, naqueles arquivos, naquela hora (e naquela 'branch').

É sempre importante darmos um 'nome' para nosso commit, pois apenas com o ID que ele recebe automaticamente fica difícil de identificar rapidamente quais as alterações no commit.

Exemplo: git commit -m 'Descrição do nosso commit'.

pull

O comando pull é usado para 'puxarmos' as atualizações, ou seja, para capturarmos as atualizações feitas no repositório remoto de origem e trazermos para nosso ambiente local. Fazemos isso com o comando git pull.

pull request (PR)

O Pull Request (PR) é usado quando finalizamos uma feature e queremos que fique disponível para outros usuários e/ou em outros repositórios remotos (de um mesmo projeto). Então abrimos essa PR para que outros possam visualizar esses códigos. Para concluir o processo do PR, o código atualizado é revisado e, se estiver tudo certo, a branch com a nova feature é mergeada com a branch desejada.

push

O comando push é usado para 'empurrarmos' as atualizações, ou seja, para subirmos as atualizações feitas no ambiente local para o repositório remoto de origem. Fazemos isso com o comando git push.

Podemos ainda especificar para qual branch e repositório queremos enviar as atualizações:

git push origin master - no caso estamos enviando as atualizações para o repositório de origem na branch master.

stage

Quando vamos preparar um commit (um pacote de atualizações), precisamos salvar os arquivos alterados e depois adicioná-los ao stage. Somente assim conseguimos 'commitar' as alterações para então enviar as atualizações para repositórios remotos. Esse stage então agrupa todas as atualizações que serão enviadas no próximo commit.

Principais comandos do git

Sempre vale a pena acessar a documentação de cada ferramenta ou linguagem que estudamos. Mas, para facilitar seus estudos, temos uma listinha com os principais comandos:

git add

Adiciona as alterações do ambiente atual para stage. Conseguimos selecionar o que vamos adicionar à Stage.

git add .
adiciona todas as alterações feitas em ambiente local

git add nomedoarquivo.ext
adiciona apenas um arquivo específico

git add pasta/*
adiciona todos os arquivos numa pasta específica

git checkout

Usamos o git checkout para navegarmos ou criarmos novas branches. Perceba que é o -b que indica que estamos criando uma nova branch.

git checkout -b nome-da-branch
cria e acessa uma nova branch

git checkout nome-da-branch
acessa uma branch

git clone

Carrega um repositório inteiro para a máquina onde estiver clonando. Ele cria uma pasta com o mesmo nome do repositório e com todos os arquivos e pastas do projeto dentro dessa pasta.

git clone https://github.com/usuario/repo.git
clona o repositório indicado no endereço

git commit

Fecha um pacote de alterações e atualizações. Devemos incluir uma mensagem para identificar sobre o que se trata o commit.

git commit -m 'Descrição do nosso commit'
cria um commit com o nome declarado entre aspas

git merge

Une os arquivos da branch declarada com os arquivos da branch em que estamos.

git merge feature-01
traz os arquivos de feature-01 para master

git pull

Puxa atualizações de um repositório remoto. Por padrão, puxa do repositório de origem.

git pull
puxa atualizações da mesma branch do repositório de origem

git pull origin master
puxa atualizações da branch master do repositório de origem

git push

Envia atualizações para o repositório remoto de origem.

git push
envia atualizações para a mesma branch do repositório de origem

git push origin master
envia atualizações para a branch master do repositório de origem

git stash

Salva alterações não commitadas numa branch temporária (deixando os arquivos modificados livres de alterações, em seus estados originais). Depois é possível retomar essas modificações.

git stash
salva as alterações numa branch temporária

git stash apply
retoma as modificações guardadas na branch temporária

git status

Informa se a branch no repositório atual está à frente da branch no repositório de origem e se há atualizações na branch de origem que não constam na branch do repositório local.

git status
retorna o status da nossa branch no repositório local

Como clonar um repositório git

Para clonarmos um repositório git basta seguirmos esses simples passos:

Acesse o repositório que deseja clonar

Acesse a página do repositório que deseja clonar. O endereço normalmente é composto pelo site do github + nome do usuáiro + nome do repositório + '.git'. Você pode conseguir esse endereço acessando a página do repositório no GitHub e clicando em 'Clonar' ou 'Clone', conforme imagem a seguir:

No terminal, acesse a pasta onde deseja clonar o repositório. Normalmente, ao abrirmos o terminal, ele abre dentro do usuário padrão. Considerando isso, rodamos o comando para acessar a pasta onde salvaremos o repositório. Nesse exemplo, salvaremos na pasta htdocs:

cd ../../xampp/htdocs
htdocs é a pasta dentro do xampp que permite acessarmos, no Windows, esse endereço com a keyword localhost. Exemplo: localhost/repositorio.

Agora digite o comando (substituindo o endereço do repositório):
git clone https://github.com/usuario/repositorio.git

Esse comando irá criar uma pasta (no local onde rodou o comando) com o nome do repositório (e todas suas pastas e arquivos).

Por fim, basta acessar a pasta do seu repositório clonado, com o seguinte comando:
cd nome-do-repositorio

Como baixar as atualizações do repositório original?

Depois que já temos nosso repositório em ambiente local, é necessário sempre mantê-lo atualizado. Para isso, sempre que vamos iniciar uma tarefa, rodamos o git pull. Esse comando baixa as novidades do repositório para nossa máquina.

Podemos definir deonde iremos baixar as atualizações espeficicando qual o repositório e a branch.

git pull
ao rodar esse comando, estamos puxando as atualizações da branch de mesmo nome da que estamos, do repositório de origem.

git pull origin master
nesse caso, estamos definindo que queremos puxar as atualizações da branch master do repositório remoto de origem.

Fechando o pacote de atualizações para podermos subir para o repo remoto

Para podermos subir atualizações para os outros devs do nosso time (ou para subir para o repositório online, remoto, de origem), precisamos antes fechar as atualizações em um ou mais pacotes. Essas atualizações devem ser agrupadas em um pacote que faça sentido (ex.: atualização do menu, bugfix de erro de login...).

Manter nossos commits organizados facilita não só a manutenção de nossos códigos como a compreensão do fluxo do projeto de maneira geral (manter essa organização pode nos poupar horas de trabalho posteriormente). Então crie o hábito de manter seu repositório organizado desde já!

Agora que sabemos que o commit é um pacote de atualizações agrupadas, precisamos entender o stage. Stage é um 'lugar' onde temos várias atualizações adicionadas e prontas para serem agrupadas num commit. Ao rodar o comando de commit, empacotamos todas as atualizações que tenham sido adicionadas ao stage.

Então, de forma geral, nós:

1. Alteramos ou adicionamos nosso código
2. Salvamos esses arquivos
3. Adicionamos esses arquivos ao stage com o comando
   git add
4. Fechamos o pacote com
   git commit

Estamos quase lá! Apenas algumas observações sobre esses dois comandos:

git add

O add é um comando que executamos para enviar as atualizações salvas em nosso ambiente local para stage (explicado mais adiante). Basicamente estamos dizendo 'vou querer agrupar essas alterações no próximo commit'. Fazemos isso com o comando git add *, sendo que o * na verdade deve ser subsituído por:

• . para selecionarmos todas as alterações feitas em ambiente local,
• nomedoarquivo.ext para adicionarmos apenas um arquivo específico,
• pasta/* para selecionar todos os arquivos numa pasta específica.

Exemplos completos:
git add .
git add meu-arquivo.txt
git add assets/js/*

git commit

O commit nada mais é do que um pacote de alterações que fizemos nos arquivos e pastas. Cada commit possui um ID próprio, para que possamos localizá-lo posteriormente. Esse ID irá referenciar ao commit, que é o pacote de atualizações feitas naquele projeto, naqueles arquivos, naquela hora (e naquela 'branch').

É sempre importante darmos um 'nome' para nosso commit, pois apenas com o ID que ele recebe automaticamente fica difícil de identificar rapidamente quais as alterações no commit.

Exemplo: git commit -m 'Descrição do nosso commit'.

git push

Leia o próximo card para entender como enviar suas atualizações para as nuvens!

Como subir as atualizações do repositório local pro remoto?

Quando finalizamos uma tarefa (ou task), precisamos disponibilizar essas atualizações para o resto do time. Para isso, rodamos o git push. Esse comando sobe as novidades do repositório para o repositório de origem (para que outros possam dar um git pull e baixar nossas atualizações).

Podemos definir para onde iremos subir as atualizações espeficicando qual o repositório e a branch.

git push
ao rodar esse comando, estamos subindo as atualizações para a branch de mesmo nome da que estamos, do repositório de origem.

git push origin master
nesse caso, estamos definindo que queremos subir as atualizações para a branch master do repositório remoto de origem.

Como trazer nossos updates para a branch principal do projeto?

Já vimos que o git push sobe nossas atualizações para o repositório remoto. Mas se você criou tudo numa branch difefente (que é a maneira correta), como proceder?

Ao realizar o push de uma branch nova, você se deparará com uma mensagem sugerindo que acesse um link para abrir um Pull Request. Não se preocupe, está tudo certo! Esse Pull Request (PR), permitirá que seus colegas revisem o código (Code Review) e aprovem seu PR para, depois, mergear sua nova branch com a master (ou develop ou branch de trabalho) - o merge está descrito no próximo card. Mas antes...

Acesse o link sugerido ou acesse seu repositório remoto (no github.com) e abra seu PR.

Ao abrir sua PR, o primeiro passo é definir qual branch receberá sua branch finalizada. Normalmente nós mergeamos uma branch nova com a branch de desenvolvimento ou homologação - mas isso depende do git flow (ou fluxo de trabalho no git) que estamos utilizando. Esse ponto é muito importante, pois se direcionar seu PR para a branch errada pode dar muita dor de cabeça.

Em seguida nomeamos o PR (normalmente virá com o nome do último commit) e descrevemos a task/branch. É uma boa prática mencionar qual o cenário em que sua feature/recurso/novidade é aplicada, como o dev que fará o code review deve navegar e testar. Quanto mais explicativa, clara e objetiva for sua descrição, melhor!

Depois você ainda pode adicionar reviewers sugeridos (quem você quer que revise seu código), indicar o responsável pela PR (provavelmente você mesma(o), adicionar labels (rótulos) e outros detalhes.

Por fim, você abre o PR e aguarda alguém aprová-lo (o reviewer ou revisor irá ver tanto a funcionalidade quanto o código).

Uma vez aprovado o PR, podemos 'mergeá-lo' - veja no card a seguir como fazer o merge.

Como trazer as atualizações de uma branch específica para outra?

Depois que nosso PR é aprovado, precisamos mesclar com a branch com as novidades com a branch de desenvolvimento ou principal. Então precisaremos 'mergear' essas duas branches (perceba que uma branch receberá as atualizações de outra).

O primeiro passo é acessarmos a branch que receberá as atualizações. Para isso usaremos o git checkout:

git checkout branch-x
essa 'branch-x' deve ser a branch que receberá as novidades

git merge branch-y
estamos trazendo as atualizações da 'branch-y' para a 'branch-x'

Pra finalizar, é necessário subir a atualização da branch que recebeu o merge (no caso, a branch-x). Para isso basta rodarmos o git push origin branch-x e a branch no repositório remoto de origem receberá nosso merge! =)