Versionando com GIT

O QUE É GIT

E você? Sabe o que é GIT? Basicamente é um sistema de controle de versões , também conhecido como SCM (Source Code Management) é um software que se encarrega de gerenciar as mudanças nos arquivos. Esses arquivos podem ser de qualquer tipo, scripts, documentos, planilhas, imagens, etc.

Esse gerenciamento mantém todo o histórico de alterações em determinado arquivo ou pastas, quem fez tal mudança, quando esta foi feita e, idealmente, porque esta alteração foi implementada, entre outras funcionalidades associadas à segurança e organização de arquivos e suas versões.

Com a evolução da tecnologia e das metodologias ágeis (como a cultura DevOps) é fundamental usar um SCM para todas as configurações e códigos que você irá produzir.

Para este tutorial usaremos o GITHUB que é um dos SCM’s mais famosos e utilizados do mundo. Então, caso não tenha sua conta, ai vai o primeiro passo:

**CRIE SUA CONTA! **É bem simples, basta entrar no site do github e seguir os procedimentos de criação de conta.

INSTALAÇÃO DO GIT

Para que possamos controlar a versão dos nossos códigos precisamos instalar o Git, que na prática é a ferramenta responsável por fazer todo o controle de versão e rastreabilidade.

Ubuntu/ Debian:

apt install git

Para validar a instalação no terminal execute:

git --version

Como o princípio do GIT é a rastreabilidade de tudo que foi alterado no código, a primeira coisa que iremos fazer é registrar na configuração é o Nome e Email que queremos que apareça ao fazer commit. Execute:

git config --global user.name "IronLinux"

git config --global user.email "[email protected]"

Lembrem-se de colocar o seu username e o e-mail utilizado para o cadastro na ferramenta.

HANDS ON!!! CRIANDO UM REPOSITÓRIO LOCAL Vamos númerar as execuções em steps para melhor compreensão

A primeira coisa que você precisa entender é que o Git gerencia repositórios, e repositórios basicamente são pastas. Então você pode pegar qualquer pasta em seu computador que pode ter arquivos e subpastas e falar para o Git começar a gerenciar isso como se fosse um repositório.

A vantagem de se fazer isso é que a partir do momento que você entrega essa pasta para o Git como repositório você terá a rastreabilidade de tudo que foi alterado. Chega dessa vida de criar versão de arquivo de configuração ou código criando uma cópia com outro nome:

script.sh
script_agora_vai.sh
script_2021_version2.sh

Vamos agora de forma prática aprender os principais comandos do git para que possamos aplicar o conceito de Controle de Versão em tudo. Indicamos que executem todos os passos para que possa absorver melhor o conteúdo.

1- Antes de começarmos, vamos ver se configuraram seu nome e e-mail de forma correta. Digite:

git config --list

2- Vamos começar a explorar o Git criando um repositório local, no meu caso criei um diretório de exemplo no caminho: ~/meu_repositorio
Então entre no diretório que irá escolher para versionar:

cd ~/meu_repositorio

3- Bem parecido com o Vagrant , também precisamos informar ao GIT que queremos tornar uma pasta um repositório e para isso usando o comando de inicialização do Git:

git init

Repare que ele apenas criou uma pasta oculta dentro do diretório para fazer todo o controle de versão:

4- Nosso primeiro comando será para checar o status do repositório. Como ele não tem conteúdo, ele apenas irá informar que não há commits e que estamos na Branch Master.

git status

5- Crie um arquivo dentro da sua pasta de exemplo chamado README.md, coloque a mensagem abaixo, salve e feche.

vim README.md

-- Primeiro Repositório Git --

6- Execute novamente o comando git status e vejá a diferença. Como acabamos de criar o README.md ele informará que há um arquivo não rastreado (Untracked), ou seja, o git ainda não está controlando a versão desse arquivo, para isso acontecer precisamos adicioná-lo ao commit.
Repare que o arquivo não rastreado fica vermelho.

git status

7- Vamos adicionar as modificações para o próximo Commit e executar o git status novamente para vermos a diferença. Já temos mudanças para serem commitadas e tamém a cor mudou de vermelho para verde.

git add --all

git status

8- Para realizar um commit é ideal e boa prática sempre redigir uma mensagem que irá dizer o que o seu commit está fazendo no código/ repositório. Como por exemplo: “Corrigindo a vulnerabilidade X”, “Adicionando a Feature Z”, etc. Em nosso caso estamos criando o arquivo Readme:

git commit -m "Criando o arquivo Readme"

9- Veja o histórico de versões do seu repositório:

git log

ou para mais detalhamento:

git log -p

FAZENDO E DESFAZENDO ALTERAÇÕES NO REPOSITÓRIO

Vamos fazer algumas atividades dentro do nosso repositório local para aprender um pouco mais sobre o gerenciamento do GIT. A ideia é você entender que quando uma pasta (repositório) está sendo controlada pelo GIT você não pode tratá-la simplesmente como uma pasta que tem arquivos e subpastas. Toda alteração no repositório precisará sempre informar ao GIT o que você espera que aconteça com essa alteração.

10- Primeiro edite o arquivo README.md e ADICIONE ao final do arquivo todos os comandos que você já aprendeu de git sendo um em cada linha. Estamos aqui simulando alterações em arquivos.

vim README.md

Vai ficar assim, por exemplo:

-- Primeiro Repositório Git --
Comandos já aprendidos:
git init
git status
git config
git add --all
git commit -m
git log
git log -p

11- Após salvar o arquivo execute git status e perceba que ele identifica que o README.md foi alterado:

git status

12- Vamos imaginar que essa alteração foi indevida ou feita de forma errada, você pode desfazer antes de adicionar ao próximo commit executando o comando abaixo:

git checkout -- README.md

Veja que todas as alterações foram desconsideradas e o repositório não tem alterações pendentes para o próximo commit. Aposto que neste ponto você já está se perguntando porque não utilizava isso antes, não?

13- Adicione novamente o conteúdo no README.md (step 10) e veja o status:

git status

14- Vamos criar um novo arquivo chamado example.txt em nosso repositório e ver o status:

touch example.txt

git status

Veja que o GIT identificou que o README.md foi alterado e um novo arquivo foi adicionado ao repositório que ele ainda não está monitorando.

15- Para ambas alterações é necessário adicionar no próximo commit com o comando abaixo, aproveite e veja o status de novo:

git add --all

git status

16- Tente executar o comando para desfazer as alterações do README.md novamente:

git checkout -- README.md

Perceba que o comando não teve efeito nenhum, pois o arquivo já foi adicionado no próximo commit. E agora, como desfazer uma operação depois que foi dado o “git add”?

17- Primeiro precisamos retirar ele do próximo commit com o reset:

git reset HEAD README.md

git status

18- Agora vamos fazer o checkout e ver as mudanças que foram feitas:

git checkout -- README.md

git status

Veja que o arquivo está sem os comandos do Git novamente e ao executar status ele nem considera mais o README.md, pois nada foi alterado desde o último commit.

19- Refaça a inserção do conteúdo no README.md novamente (step 10 and step 13):

20- Vamos enviar para o próximo commit:

git add --all

git status

21- Vamos executar o commit e ver o status e o log:

git commit -m "Atualização do README e envio Example.txt"

git status

git log

22- E se você quiser desfazer a alteração depois de ter commitado? Bom, o primeiro passo será desfazer o commit (veja que o último log foi retirado):

git reset --soft HEAD~1

git log

23- Depois retiramos o README.md da área de Staging:

git reset HEAD README.md

git status

23- Por último remova a alteração feita no arquivo e veja o status:

git checkout -- README.md

git status

24- Veja que demos rollback no README.md porém o arquivo example.txt continua na lista para ser aplicado no próximo commit. Retorne as alterações no arquivo README.md, adicione as alterações, faça o commit com a mesma mensagem do commit anterior, ou seja, refaça os últimos itens.

git add --all

git commit -m "Atualização do README e envio Example.txt"

git log

Vamos de resumão do que vimos até agora?

Aprendemos que para fazer alterações em nosso repositório sempre vamos precisar rodar o comando “git add” e depois finalizar com um “git commit” se quisermos de fato controlar as versões de nossas alterações. Em contrapartida também vimos que para desfazer uma ação dentro de nosso repositório existem passos diferentes dependendo do status do nosso repositório:

Se quisermos desfazer as alterações em um arquivo antes de adicionar o mesmo na área de Stage para o próximo commit:

git checkout -- README.md

Se já tivermos adicionado as alterações na área de Stage:

git reset HEAD README.md

git checkout -- README.md

Se já tivermos feito o commit:

git reset --soft HEAD~1

git reset HEAD README.md

git checkout -- README.md

Esses foram rollbacks seguros, onde você sabe exatamente o que está desfazendo e por etapa.
**Existe uma opção mais agressiva caso você tenha certeza que quer desfazer todas as alterações do último commit:
**

git reset --hard HEAD~1

Se executar esse comando, verá que além de desfazer as alterações do README o arquivo example.txt também é apagado.

GERENCIANDO REPOSITÓRIOS REMOTOS

Agora que você já sabe os comandos básicos do GIT, vamos associar nosso repositório local a um repositório remoto no GitHub.

Nesse momento nós temos um repositório local em nossa máquina chamado ‘meu_repositorio’(no meu exemplo) e iremos enviar para um repositório remoto no GitHub.

A primeira coisa que precisa ser feita para gerenciar seu repositório remoto, é configurar uma chave SSH de seu Desktop no GitHub para ser possível clonar repositórios ou enviar código para o repositório remoto sem a necessidade de login e senha.

1- No terminal em seu Linux execute o comando para gerar a chave e preencha como julgar necessário:

ssh-keygen

2- Copie o hash da sua chave, caso não tenha alterado o nome e o caminho será:

cat ~/.ssh/id_rsa.pub

3- Acesse as configurações de seu GitHub na sessão de Chaves SSH, link direto e clique em ‘New SSH Key’, preencha o Nome da chave em ‘Title’ e o cole o conteúdo em ‘Key’:

https://github.com/settings/keys

4- Agora podemos criar nosso primeiro repositório Remoto, acessando o site do gihub logado, clique:

• no ‘botão + no canto superior esquerdo"
• New Repository
• Preencha o nome do seu repositório, no meu caso “meu_repositorio”
• Desmarque a opção “Add a README file” em “Initialize this repository with”

5- Na sequência precisamos voltar em nosso repositório local no terminal e informar qual será o nosso repositório remoto no GitHub. Digite o comando abaixo, alterando o seu usuário onde esta ‘ironlinux’:

git remote add origin [email protected]:ironlinux/meu_repositorio.git

6- Agora vamos enviar nosso Commit para o repositório remoto:

git push origin master

Veja que apareceu a mensagem do Fingerprint sobre a primeira conexão com este serviço SSH, preencha ‘yes’. Agora abra o github e vá ao repositório que você criou. Viu quem está lá? Isso mesmo os nossos arquivos que brincamos e mexemos anteriormente. Parabéns você acaba de enviar seu primeiro commit para um repositório remoto.

GIT IGNORE

O GIT tem uma funcionalidade chamada .gitignore que nada mais é que um arquivo texto onde você pode colocar a lista de arquivos que você não quer controlar com o git ou enviar para o seu repositório remoto. Geralmente arquivos de logs, chaves são arquivos que você não vai querer em seu repositório remoto. Uma dica é usar o site https://www.gitignore.io para gerar seu arquivo .gitignore com base no objetivo de seu repositório.

1- Crie um arquivo com um nome ficticio, no meu caso, criei o arquivo ‘keys.txt’

touch keys.txt

2- Crie em seu repositório o arquivo .gitignore com o conteúdo gerado no gitignore.io:

# Created by https://www.toptal.com/developers/gitignore/api/git
# Edit at https://www.toptal.com/developers/gitignore?templates=git

### Git ###
# Created by git for backups. To disable backups in Git:
# $ git config --global mergetool.keepBackup false
*.orig

# Created by git when using merge tools for conflicts
*.BACKUP.*
*.BASE.*
*.LOCAL.*
*.REMOTE.*
*_BACKUP_*.txt
*_BASE_*.txt
*_LOCAL_*.txt
*_REMOTE_*.txt

### Key ###
keys.txt

# End of https://www.toptal.com/developers/gitignore/api/git

Veja que no git status foi ignorado o arquivo que colocamos no .gitignore

3- Agora adicione o .gitignore no stage e depois faça o commit e envie para o repositório remoto:

git add --all

git commit -m "Enviando gitignore"

git status

git push origin master

Veja que não foi enviado o arquivo que colocamos no gitignore nem para o commit e nem para o repositório remoto:

git log

GIT BRANCH

Git Branch - Local

Até o momento fizemos alguns commits do nosso código de exemplo sem se preocupar muito se nossas alterações tem ou não conflito de código ou se tem mais gente mexendo no mesmo momento que a gente. Num termo mais técnico podemos dizer que todos os nossos commits foram feitos direto na Branch Master, com o comando “git push origin master”.

O que são Branchs?

O GIT trabalha com um conceito de Branch para nos ajudar na organização e no fluxo de desenvolvimento como um todo.

Quando queremos adicionar um novo recurso ou corrigir um bug em nosso código, independente do tamanho dessa alteração, o aconselhável é que você sempre crie uma branch para “isolar” aquela mudança até a mesma estar completamente desenvolvida e ai sim ser unido ao código principal através do merge na branch principal.

Quando você cria uma nova branch é como se o GIT “clonasse” todo o conteúdo do seu repositório em um “compartimento” isolado para que você possa mexer com segurança sem “estragar” o seu código original.

Manipulando Branchs no Git

Vamos agora criar uma branch para entender como gerenciá-las.

HANDS ON!

1- Antes de criar uma branch, liste as branches disponíveis em seu repositório:

git branch

Veja que só temos a Branch principal que o GIT nomeia de Master.

2- Vamos criar uma nova Branch para fazer algumas mudanças em nosso repositório de forma segura protegendo nosso projeto principal:

git branch slave

git branch

Veja que agora temos 2 branchs em nosso repositório onde a master aparece com um ASTERISCO e marcada com a cor VERDE, isso significa qual a Branch que está ativa nesse exato momento, ou seja, caso você faça uma alteração no código, estará aplicando essa alteração na branch master e a branch Slave que foi a que criamos.

3- Nosso objetivo é novas alterações serem feitas na branch slave. Para isso precisamos selecionar a branch slave com o seguinte comando:

git checkout slave

git branch

Dica: É possível criar e selecionar uma branch com apenas um comando:

git checkout -b slave

4- Vamos agora criar um novo arquivo em nosso repositório ‘meu_repositorio’ chamado ’example_branch.txt’ com o conteúdo ‘sample file ‘para testarmos esse fluxo de não mexer no código principal:

vim example_branch.txt

sample file

5- Execute git status e repare na primeira linha da saída desse comando que ele mostra em qual Branch (ramo) essa alteração está sendo feita:

git status

6- Agora adicione o novo arquivo no próximo commit e realize o commit:

git add --all

git commit -m "Adicionando o Arquivo example_branch.txt"

git status

7- Execute o git log e repare que ele irá listar os commits referenciando a branch a qual eles pertencem:

git log

DICA: utilize o comando abaixo para exibir o log de forma simplificada

git log --pretty=oneline --abbrev-commit

8- Vamos alterar para a Branch Master e listar o diretório. Você verá que o arquivo example_branch.txt não estará na listagem, pois ele foi adicionado na Branch slave, ou seja, quando usamos branchs as mudanças ficam isoladas nas respectivas ramificações:

git checkout master

git branch

git status

ls

Agora você já sabe trabalhar com Branch Local! O fato de ter criado essa branch não significa que ela foi para o GitHub.

Git Branch - Remoto

Nesse momento, se você entrar no GitHub verá que a Branch slave não consta no repositório remoto. Isso acontece porque do mesmo jeito que tínhamos que enviar nossas alterações para o repositório da branch master, a gente precisa fazer isso para a branch slave também.

É importante não esquecer de enviar suas alterações para garantir uma redundância do seu código no repositório remoto, caso aconteça algo em sua máquina, como também para garantir que todas as pessoas que possam estar trabalhando no mesmo repositório que você tenham a última versão das mudanças que você fez.

1- Vamos selecionar a branch slave e fazer o envio das alterações para o nosso repositório remoto:

git checkout slave

git branch

git push origin slave

Veja que ele criou uma nova Branch também em seu repositório remoto e o comportamento é o mesmo, se selecionar a branch Master não verá o arquivo ’example_branch.txt’ e se selecionar a Branch slave o arquivo estará lá.

REPOSITÓRIO FINAL QUE USAMOS: https://github.com/ironlinux/meu_repositorio

That’s all, folks!