Usando o Git – parte 4

Git-4_atom_markdown

A partir deste ponto o fluxo de trabalho do Git já deixou de ser novidade;  assim como também o utilizar branches, recuperar arquivos de commits anteriores e até indicar à ferramenta como ignorar determinados arquivos no diretório de trabalho. Agora é chegada a hora de utilizar o Git para o propósito ao qual ele foi desenvolvido, ou seja, o compartilhamento do repositório para permitir o trabalho distribuído. 🙂

Um pouco de história

No ano de 2002 o BitKeeper foi escolhido para ser a ferramenta de controle de versão no desenvolvimento do Linux; (na época) ele tinha licença proprietária mas seu uso estava liberado para projetos em software abertos e livres — desde que os desenvolvedores não participassem de projetos para o desenvolvimento de uma ferramenta similar.

Em 2005, alegando que estavam fazendo engenharia reversa nos protocolos da ferramenta, a liberação para uso “comunitário” foi revogada e, por falta de uma alternativa melhor, Linus Torvalds acabou escrevendo o Git para substituir o BitKeeper e o resto é história.

E em maio de 2016 a licença do BitKeeper foi alterada para a Apache License 2.0.

Compartilhamento

Até o momento trabalhamos apenas em um repositório único e localizado dentro da máquina virtual do Vagrant, portanto:

$ cd ~/Vagrant/usando_o_git
$ vagrant up --provider virtualbox

E sem usar vagrant ssh, ao menos por enquanto. 🙂

Utilizado SSH

Como foi construído para ser um sistema distribuído não existe no Git a figura de um servidor que cuida da tarefa de manter o repositório, a própria ferramenta cuida disso e utiliza diversos protocolos para permitir a transferência dele.

O modo mais fácil de copiar um repositório é usando SSH¹:

$ mkdir ~/Git
$ cd ~/Git
$ git clone ssh://ubuntu@127.0.0.1:2222/home/ubuntu/pastelaria
Cloning into 'pastelaria'...
ubuntu@127.0.0.1's password: 
remote: Counting objects: 39, done.
remote: Compressing objects: 100% (37/37), done.
remote: Total 39 (delta 17), reused 0 (delta 0)
Receiving objects: 100% (39/39), 4.04 KiB | 0 bytes/s, done.
Resolving deltas: 100% (17/17), done.
Checking connectivity... done.

Pronto, ele foi “clonado” com sucesso, isto é, não só o conteúdo dos arquivos como o histórico de alterações do repositório foram transferidos da máquina virtual (origem).

Veja só:

$ git shortlog
Giovanni Nunes (12):
 Abertura da pastelaria
 pastéis de carne e queijo
 pastéis doces
 novos pastéis para teste
 inclusão das bebidas
 mesclando 'cardápio'
 mesclando 'doces'
 mudança no carne com ovo
 carne com ovo de volta à receita original
 manutenção nos arquivos
 adicionando o .gitignore
 remoção dos arquivos monitorados

A vantagem de usar o SSH é justamente a praticidade já que não é preciso adicionar nada à infraestruturada original e a desvantagem é claramente se precisar disponibilizar login, senha, chave etc para quem precisar de acesso.

(¹) Três considerações : (i) apesar de estar usando a box oficial do Ubuntu 16.04 ela não segue totalmente as recomendações da Hashicop quanto ao nome padrão de usuário ou mesmo os pacotes instalados, (ii) a URL utilizando a porta 2222 faz parte do redirecionamento provido pelo Vagrant para acesso da máquina virtual e (iii) se você não sabe qual é a senha do usuário ‘ubuntu’, troque-a pois agora não tenho certeza ser também ‘ubuntu’. 🙂

Usando outras formas de compartilhamento

Apesar de não existir um “servidor de git” há serviços que foram construídos ao redor dele e que permitem a criação, manutenção e o gerenciamento de repositórios através de uma interface web e que acrescentam outras funcionalidades como wiki, controle de ocorrências, restrição de acesso etc.

Mas como a ideia aqui não é citar todos os que existem, na Wikipédia há um comparativo suficientemente completo, vou citar rapidamente os que conheço e utilizo.

GitHub

Git-4_GitHub.png

O GitHub é o mais conhecido deles, tanto que as vezes ele se confunde com o próprio Git. No plano gratuito é permitido criar um número ilimitado de projetos (repositórios) com número também ilimitado de colabores. E claro, tem a figura carismática da/do Octocat!

Bitbucket

Git-4_Bitbucket

O BitBucket é mantido pela Atlassian, oferece a manutenção tanto de repositórios Git quanto Mercurial e diferente do GitHub até permite manter repositórios privados no plano gratuito só que limitado-os a ter até cinco usuários cadastrados.

GitLab

Git-4_GitLab

O GitLab é o mais novo dos três e talvez por este motivo ofereça um “pacote” mais tentador no plano gratuito, isto é, você pode criar quantos repositórios públicos ou privados quiser e sem limitação na quantidade de usuários participantes.

De volta à Pastelaria

A pastelaria agora tem uma filial e ambas precisarão fazer modificações nos cardápios e por este motivo foi criado um repositório no GitHub — pois é, a gerência não está preocupada com o cardápio tornado público por aí ou simplesmente não se deu conta do fato… 🙂

Criando um repositório no GitHub

A primeira parte é criar o repositório:

Git-4_github_novo_repositorio 1

Novo repositório no GitHub e opções para já criar os arquivos README.md e .gitignore

Mas como o Git saberá que é para pegar ou colocar as coisas nestes novo repositório? A primeira parte desta pergunta se responde na página seguinte:

Git-4_github_novo_repositorio 2

Após a criação, as diversas opções para popular o repositório

Daí é ir até a máquina virtual do Vagrant — finalmente! — e fazer:

$ vagrant ssh
$ cd ~/pastelaria
$ git remote add origin https://github.com/plainspooky/pastelaria.git
$ git push --set-upstream origin master
Username for 'https://github.com': plainspooky
Password for 'https://plainspooky@github.com': 
Counting objects: 39, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (37/37), done.
Writing objects: 100% (39/39), 4.04 KiB | 0 bytes/s, done.
Total 39 (delta 17), reused 0 (delta 0)
To https://github.com/plainspooky/pastelaria.git
 * [new branch] master -> master
Branch master set up to track remote branch master from origin.

Como o comando remote eu defini um repositório remoto chamado “origin” e informo a localização dele — o arquivo “.git” e com o comando push eu sincronizo meu ramo master com o ramo master de “origin” (o upstream, ou seja, para onde envio). Como ele estava vazio todos os objetos foram enviados para lá. Aliás, da próxima vez não será necessário indicar quem é o upstream, esta informação foi armazenada.

E pronto, tanto os arquivos  quanto o histórico de alterações estão agora disponíveis publicamente em um repositório do GitHub.

Clonando a partir do GitHub

Desejando cloná-lo para um outro lugar basta fazer:

$ git clone https://github.com/plainspooky/pastelaria.git
Cloning into 'pastelaria'...
remote: Counting objects: 39, done.
remote: Compressing objects: 100% (20/20), done.
remote: Total 39 (delta 17), reused 39 (delta 17), pack-reused 0
Unpacking objects: 100% (39/39), done.
Checking connectivity... done.

Ah sim, para clonar um repositório (público) não há necessidade de autenticação mas para enviar alterações é necessário ter uma conta no GitHub, ok?

Enquanto isto…

Enquanto o repositório era criado no GitHub a gerência da filial teve a brilhante ideia de clonar o cardápio diretamente via SSH da máquina virtual e de já fazer algumas alterações:

filial:$ git add --all
$ git commit -m "primeiro commit da filial"
[master 1c6397b] primeiro commit da filial
 2 files changed, 1 insertion(+), 2 deletions(-)
 create mode 100644 desenho_do_pastel.png

Só que isto criou um problema pois o repositório deles ficou configurado da seguinte forma:

filial:$ git remote show origin
ubuntu@127.0.0.1's password: 
* remote origin
 Fetch URL: ssh://ubuntu@127.0.0.1:2222/home/ubuntu/pastelaria
 Push URL: ssh://ubuntu@127.0.0.1:2222/home/ubuntu/pastelaria
 HEAD branch: master
 Remote branches:
 cardápio tracked
 doces tracked
 master tracked
 Local branch configured for 'git pull':
 master merges with remote master
 Local ref configured for 'git push':
 master pushes to master (fast-forwardable)

Portanto, é necessário corrigir isto antes de enviar as alterações ao repositório do GitHub²:

filial:$ git remote remove origin
filial:$ git remote add origin https://github.com/plainspooky/pastelaria.git
filial:$ git push -u origin master
Username for 'https://github.com': plainspooky
Password for 'https://plainspooky@github.com': 
Counting objects: 4, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 10.81 KiB | 0 bytes/s, done.
Total 4 (delta 2), reused 0 (delta 0)
To https://github.com/plainspooky/pastelaria.git
 cf81176..1c6397b master -> master
Branch master set up to track remote branch master from origin.

E pronto, alterações enviadas e a partir de um outro canto.

(²) Como o Git é descentralizado e não haveria problema de enviar as alterações diretamente para o repositório da máquina virtual; aqui é uma questão de praticidade.

Atualizando o repositório local

Para atualizar (melhor seria dizer “sincronizar”) o repositório local com os arquivos do GitHub use:

$ git pull
remote: Counting objects: 7, done.
remote: Compressing objects: 100% (5/5), done.
remote: Total 7 (delta 4), reused 4 (delta 2), pack-reused 0
Unpacking objects: 100% (7/7), done.
From https://github.com/plainspooky/pastelaria
 cf81176..e027e07 master -> origin/master
Updating cf81176..e027e07
Fast-forward
 README.md | 3 +--
 desenho_do_pastel.png | Bin 0 -> 10699 bytes
 2 files changed, 1 insertion(+), 2 deletions(-)
 create mode 100644 desenho_do_pastel.png

Daí é seguir naturalmente com o fluxo de trabalho do Git e terminar com git push para enviar suas alterações de volta.

Considerações finais

Assim esta “série” chega ao final tendo tratado dos conceitos essenciais da utilização do Git apresentando tanto teoria quanto prática — que os gerentes de pastelarias me perdoem, nada tenho contra eles… 🙂 — Para saber um pouco recomendo o git — guia prático — sem complicação do Roger Dudler e também o git-tips que contém uma lista extensa com exemplos de sintaxe do Git para se executar diversas ações.

E como o uso e operação das opções disponíveis dentro do GitHub (assim como também existem dentro do Bitbucket e no GitLab) fogem um pouco do escopo inicial e até podem ficar para uma próxima vez… Principalmente o GitLab que tem tem opções bem interessantes.


O repositório da pastelaria foi disponibilizado no GitHub e ficará lá para quem quiser se divertir com ele.

Anúncios

Um comentário sobre “Usando o Git – parte 4

  1. Pingback: Usando o Git, quarta parte - Linux em Ação XYZ

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s