Se você leu o meu último post sobre o Git, já deve ter percebido que o Git é um sistema muito poderoso e que facilita o trabalho em equipe ao fornecer recursos para facilitar isso, como branches e registro do autor de cada commit. No mesmo post, eu ainda apresentei o fato que torna o Git distribuído: A possibilidade de usar qualquer repositório git em um computador remoto para sincronizar o conteúdo do seu repositório local, e como isso poderia permitir o uso do git como um sistema P2P.
Pois bem, é verdade que é possível usar o Git como um sistema P2P, mas isso não é muito prático, pois o não implementa uma forma de "consenso" nesse estilo de requisição, ou seja, você pode sincronizar repositórios Git entre duas máquinas (como entre o seu computador e um servidor, por exemplo), tranquilamente, mas se o número de máquinas é maior que dois, a situação começa a complicar.
Devido a isso, é comum o uso do Git com sistemas de hospedagem de repositórios, que funcionam como uma "central" no qual os repositórios são armazenados (servindo também como backup, portanto) e que serve como meio de sincronização entre 2 ou mais máquinas possuindo um determinado repositório Git. E hoje, vou falar um pouco sobre as variadas opções que temos disponíveis, e ensinar como integrá-las com o seu repositório git feito no post anterior.
Mas, o que são esses sistemas de hospedagem de repositórios? Bom, numa descrição simples são..sistemas que permitem hospedar e gerenciar repositórios com facilidade. Com um sistema desses você pode, por exemplo:
- Compartilhar repositórios com conhecidos ou com a comunidade facilmente;
- Visualizar e navegar pela estrutura dos diretórios facilmente;
- Disparar hooks para variados serviços conforme os pushes (envios) são feitos;
- Receber pull requests, que são "merges" que as pessoas podem enviar para o repositório mas que precisam de autorização de alguém autorizado do repositório para que o merge seja realizado, permitindo assim o review de código antes de uma modificação grande ser aceita, por exemplo;
- Criar organizações (grupos de repositórios) e controlar o acesso de cada equipe a cada repositório;
- Registrar e acompanhar issues (falhas, sugestões, etc.) relacionados ao repositório/projeto;
- Permitir comentários em commits;
- Entre outras funções;
Como você pode ver, muitas dessas tarefas ampliam muito a gama de possibilidades que os repositórios do Git permitem, permitindo um melhor trabalho em equipe enquanto permitindo ter uma cópia central do seu repositório Git.
Agora que você já sabe um pouco das funções de um sistema de hospedagem de repositórios, precisamos saber como integrá-lo ao git instalado em seu computador, de forma que você possa enviar e receber atualizações em seu repositório a partir do sistema de hospedagem de repositórios. Nesse tutorial, vou considerar que você já teve um primeiro contato com o git a partir do tutorial básico sobre git, e que também já possui seu primeiro repositório a partir dos passos mostrados no próprio tutorial. Segue:
Tutorial básico sobre envio e recebimento de atualizações com Git
1) Para esse tutorial, precisamos primeiro registrar o host remoto no git, de forma que ele saiba como contatar o sistema de hospedagem de repositórios. No git, isso pode ser feito de duas maneiras:
- Via SSH (minha preferida) - Nesse formato, o sistema de hospedagem de repositórios te dá uma url no estilo [usuario]@[dominio]:[conta]/[repositorio].git, onde [usuario] normalmente é git, [dominio] é o dominio do sistema de hospedagem de repositórios (ex.: github.com), [conta] é o nome de usuário da sua conta ou organização registradas nesse sistema, e [repositorio] é o nome do repositório no sistema. Nesse modo, a sua chave SSH é usada para se autenticar no repositório remoto, mas acho que isso é tutorial para outro post (pois é um assunto um pouco complexo de tratar);
- Via HTTPS - Nesse formato, o sistema de hospedagem de repositórios te dá uma url no formato https://[dominio]/[conta]/[repositorio].git, onde [dominio] é o domínio do sistema de hospedagem de repositórios (ex.: github.com), [conta] é o nome de usuário da sua conta ou organização registradas nesse sistema e [repositorio] é o nome do repositório no sistema. Pessoalmente, não gosto muito desse modo, pois com ele você fica totalmente impossibilitado de usar chaves SSH para autenticação, mas ele pode ser útil para quando você prefere não usar SSH, por algum motivo aleatório;
Normalmente, é comum que os sistemas de hospedagem de repositórios suportem ambas as formas, e, particularmente, o Git não se importa muito com isso, pois o comando para ambas as formas é o mesmo: "git remote add [nome] [endereço no formato desejado]", aqui, [nome] é o nome do servidor que você deseja usar localmente. Para a escolha desse nome, alguns fatores podem ser levados em consideração: Se é servidor de deploy, se você envia o código para mais de um lugar, entre outros. Normalmente, [nome] assume o valor "origin" aqui, e é o nome que recomendo que você use no seu repositório, também (a menos, claro que por algum motivo obscuro o nome origin já esteja registrado..).
Como suponho que você ainda não tenha um endereço nesse formato ainda, resolvi criar um repositório no Github para exemplificar o uso desse comando. O repositório está localizado em https://github.com/fjorgemota/tutorial-git-basico (você pode acessá-lo, se quiser), e o endereço HTTPS que o Github forneceu é... https://github.com/fjorgemota/tutorial-git-basico.git (sim, a única diferença é o .git no final).
Portanto, considerando que o nome associado a esse repositório pelo git vai ser origin, e o endereço é https://github.com/fjorgemota/tutorial-git-basico.git, temos que o comando executado vai ser "git remote add origin https://github.com/fjorgemota/tutorial-git-basico.git". Veja a gravação (note que estou executando no mesmo repositório criado no tutorial básico de git):
Yép, é normal o git não emitir nenhuma mensagem nesse comando. Ele só adiciona e fica quietinho, na dele, só emitindo um erro se algo realmente der errado.
2) Agora, vamos enviar (ou seja, fazer push) o repositório para o repositório remoto. O push é feito pode ser feito de duas maeniras:
- Enviando todas as branches do repositório local de uma só vez, que pode ser feito usando o comando "git push --all [nome do repositório remoto]";
- Enviando apenas uma branch do repositório local, que pode ser feito usando o comando "git push [nome do repositório remoto] [nome da branch]";
Pessoalmente, eu prefiro a 2º forma, pois em último caso ajuda a diminuir a taxa de erros e me dá controle sobre o processo de deploy quando Continuous Integration e Continuous Deployment são usados, por exemplo (novamente, é assunto para outro post..acompanhe para não perdê-los), assim, é a forma que vou usar neste tutorial. Note que, como o nome do repositório remoto dado no primeiro passo foi origin, e quero a principio enviar a branch master, o comando vai ficar algo como "git push origin master". Segue a gravação dele executando:
Como você pode ver, devido ao fato da branch ainda não existir no repositório remoto, ela foi criada durante o push. E, como eu utilizei o formato HTTPS para o repositório, o Github pediu meu username e senha para poder confirmar a autenticidade do push (e checar permissões, essas coisas..).
3) Agora que enviamos o repositório, podemos fazer o pull dele. Como temos que o repositório local tutorial-git já possui os mesmos commits existentes no repositório remoto, resolvi criar um novo repositório local, chamado tutorial-git-2, e a partir dele fazer a operação de git pull. Mas, antes de fazer isso, como o repositório local tutorial-git-2 não tem nenhum conhecimento do repositório remoto, temos que registrar ele no repositório local tutorial-git-2, como fizemos no passo 1. Acompanhe os comandos executados:
Note que o git pull tem o formato "git pull [nome do repositório remoto] [nome da branch]". Note que o git pull não tem uma opção para atualizar todas as branches em uma só tacada, e também note que é importante que o [nome da branch] -->deve<-- ser igual ao nome da branch no qual você está.
No caso da gravação acima, como estávamos na branch master e queríamos atualizá-la, e como o nome do repositório remoto registrado é origin, o comando final ficou como "git pull origin master".
3.1) Nesse caso em específico, como nós fizemos download completo do repositório (ou seja, não tinhamos nenhum commit em comum com o repositório remoto), poderiamos também ter feito um clone, que é basicamente o mesmo processo, mas executado em apenas um único comando pelo git. O comando "git clone" tem o formato "git clone [endereço do repositório remoto] [nome da pasta no qual o repositório local será colocado]", e portanto o nosso comando final ficaria algo como "git clone https://github.com/fjorgemota/tutorial-git-basico.git tutorial-git-2". Veja:
Com isso, em um único comando, o git terá baixado o repositório remoto e disponibilizado para você. Simples, rápido, e eficiente, né? 🙂
Obviamente, se já tivéssemos commits em comum com o repositório remoto (como no caso no qual você apenas quer baixar as novas atualizações do repositório remoto), seria muito mais fácil e eficiente fazer apenas um git pull, pois nesse caso o git faz apenas o download dos commits que o seu repositório local ainda não possui.
Agora, onde hospedar o repositório remoto? É isso que vamos ver abaixo:
Opções de sistema de hospedagem de repositórios
Há inúmeras opções de sistemas de hospedagem de repositórios. Nesse post, resolvi abordar apenas 4, entre as mais conhecidas, e separá-las em duas categorias básicas: Disponíveis apenas online, e Instaláveis em um servidor. Algumas dessas opções serão trabalhadas mais fortemente em posts futuros. Ah, e se você tiver mais opções de sistemas de hospedagem de repositórios, não se esqueça de indicá-la nos comentários!
Disponíveis apenas na Cloud
Há 2 opções muito populares de sistemas de hospedagem de repositórios que estão disponíveis apenas online. Tá, você até consegue instalar esses sistemas atrás de um firewall ou em servidor próprio, mas somente se pagar muito caro mesmo. Enfim, continuando, segue a lista:
Github
O Github é o "sistema de hospedagem de repositórios" mais popular disponível atualmente. Seu principal diferencial dentre todos os outros sistemas é que o Github é uma rede social: Você pode seguir perfis (aliás, me segue lá!), dar star em repositórios, entrar pra lista de contribuidores dos repositórios assim que tem um pull request aprovado, e assim por diante.
Além disso, o Github é o sistema de hospedagem de repositórios mais usado por projetos open-source, e fornece um plano 100% gratuito para quem somente publicar repositórios públicos (sob o modelo open-source). Caso você queira ter repositórios privados, é preciso..pagar. (ou, se você for estudante, é possível conseguir até 5 repositórios privados de graça)
Segue o link para o site: https://github.com
Bitbucket
O Bitbucket é uma opção de sistema de hospedagem de repositórios bem..interessante. Com visual mais sério em relação ao Github, é feito pela Atlassian e fornece, além de repositórios públicos gratuitos (assim como o Github), repositórios privados gratuitamente para todo mundo, contando apenas com limites de contribuidores por repositório.
Quem quiser maior limites de contribuidores, eventualmente precisa pagar.
Segue o link do site oficial: https://bitbucket.org/
Instaláveis em um servidor
Existem opções de sistemas de hospedagem de repositórios que são instaláveis em um servidor. Essas opções normalmente são de código aberto e não possuem limites em relação a número de repositórios ou de contribuidores. Veja abaixo duas dessas opções:
Gogs
O Gogs é uma opção versátil de sistema de hospedagem de repositórios. Desenvolvido em Go, é fácil de instalar (basta executar um único binário, configurar e..pronto), tem interface amigável e tem bastante recursos. É a minha opção pessoal preferida e a uso para hospedar meus códigos mais privados por aí. =)
Segue o link do site oficial: https://gogs.io/
Gitlab
O Gitlab é uma opção mais madura do que o Gogs e igualmente poderoso. Desenvolvido em Ruby, é mais complicadinho de instalar (tem um bocadinho de dependências), mas em compensação tem mais recursos, mais documentação e também mais integração com outros projetos. Ideal para usos mais complexos.
Segue o link do site oficial: https://about.gitlab.com/downloads/
Conclusão
Com isso, dá para ver que o Git é muito mais do que apenas um simples sistema de controle de versão: Há todo um ecossistema em torno do git, e as ferramentas supracitadas só vem para ressaltar ainda mais esse ponto. Em breve, postarei aqui ainda mais posts ressaltando todo esse ecossistema, e destacando problemas comuns dos desenvolvedores que são simples de se resolver usando o que as ferramentas que se integram com o git disponibilizam.
Espero que tenham gostado do post, e do tutorial como um todo. Não deixe de acompanhar o blog e deixe o seu comentário nesse post se você tem algum comentário, critica ou sugestão. Até a próxima!
Deixe um comentário