Empurrando e puxando
Hoje vamos rever outro conceito básico porém poderoso que o GIT entre outros sistemas de controle de versão do seu tipo tem: distribuição! Como você deve saber, seus commits são todos locais, e repositórios são simplesmente clones uns dos outros. Isso significa que o trabalho real na distribuição de seus projetos está em sincronizar as mudanças através do git push e git pull.
Se você está começando com GIT, você pode pensar que isto é muito elevado e leva a uma falha de controle. Olhe para ele desta maneira: se o seu servidor central cair, você geralmente está na mão e impedido de trabalhar e colaborar com os outros. Uma vez que todos os envolvidos com o projeto tem uma revisão em sua própria máquina, você pode codificar se a rede cair, se não tiver autorização de outros ou quando esta sujeito a problemas de rede. Eu mencionei que é muito mais rápido para a maioria das operações comuns? Confira mais algumas das vantagens (e desvantagens) do DVCS na Wikipédia # Vs_Centralised.
Oliver Steele tem uma ótima imagem de como o pull e push funcionam:
A maior parte deste diagrama é fácil, faça um commit de suas alterações para a staging area. Feito isso, seu sistema de controle está atualizado, mas agora nós precisamos sincronizar com o repositório remoto. Este pode ser um site como GitHub, um servidor Git central, uma maquina de produção ou mesmo os repositórios dos colegas de trabalho. Uma vez que as alteração forem enviadas, outras pessoas podem puxar e trabalhar com elas. Como na maioria das ações no Git, existem algumas opções, mas vamos ficar com o pull por hoje.
Vamos para um exemplo real. Eu acabei de adicionar o link do Twitter no radapé deste blog. Eu preciso empurra minhas alterações para o repositório do GitHub para que eu possa atualizar o servidor. a sintaxe para este comando normalmente é git push <remote> <branch>. Onde remote é um endereço de um repositório clonado que tem os mesmos dados e histórico e está apenas esperando para receber atualizações. Normalmente a maioria dos projetos trabalham com um remote origin e o branch master por padrão.
$ git commit -am "Adding twitter link"
Created commit f2cd831: Adding twitter link
1 files changed, 1 insertions(+), 0 deletions(-)
$ git push origin master
Counting objects: 7, done.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 407 bytes, done.
Total 4 (delta 2), reused 0 (delta 0)
To git@github.com:qrush/gitready.git
361303d..f2cd831 master -> master
Agora seu repositório remoto está atualizado e se você for no GitHub você pode ver os commits. A saída deste comando mostra como o GIT tem que lidar com a transferências dos vários blocos de dados que foram alterados e então nos informa que o repositório foi atualizado, mostrando a mudança de SHA1.
Mas o que quer dizer pull? Nós podemos usar este comando para atualizar qualquer outro repositório com os commits que eu sincronizei. O projeto que tem um script de deploy ruim faz exatamente isso:
$ git pull origin master
remote: Counting objects: 7, done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 4 (delta 2), reused 0 (delta 0)
Updating 361303d..f2cd831
Fast forward
_layouts/default.html | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
O output nos mostra que o repositório no servidor teve algumas mudança em relação ao repositório remoto e então as traz. Este processo fará exatamente o mesmo para trazer alterações que outras pessoas enviarem para o seu repositório. Aqueles que tem um fork do gitready no GitHub podem agora obter as alterações que eu fiz. Em artigos futuros irei falar deste processo mais a fundo.
Se você tem outras idéias ou conceitos que não foram tratados nos informe (nós iremos manter a referência em artigos futuros).