X-Git-Url: http://git.cascardo.eti.br/?a=blobdiff_plain;f=Colaborando_com_Git.mdwn;h=bcba446223cf3ca520e87a856a55bbea6d5aab82;hb=23fe1c21e61fb38ad6d942ad59ac67b1c5a2c711;hp=f9f96c8ceb36a9a70fe17719e2649e2203baade3;hpb=d5dc76ed1aff30486e9cf981b3e203d2d0431e72;p=cursogit.git diff --git a/Colaborando_com_Git.mdwn b/Colaborando_com_Git.mdwn index f9f96c8..bcba446 100644 --- a/Colaborando_com_Git.mdwn +++ b/Colaborando_com_Git.mdwn @@ -128,7 +128,7 @@ utilizado git remote update. ~/project$ git remote update Fetching origin Fetching alice - From /home/cascardo/git/ff/project + From git://alice.example.com/project.git/ * [new branch] devel -> alice/devel ~/project$ @@ -153,4 +153,96 @@ branch remoto que é rastreado pelo branch local. O rastreamento de um branch local é importante para comandos como git push e git pull, que veremos logo mais. +## Atualizando repositórios remotos + +Após clonar ou adicionar um repositório remoto com uma URL que permite +escrita, poderemos atualizá-lo através do comando git push. + +O comportamento de git push sofreu alterações ao longo das versões de +Git. Veremos alguns destes comportamentos padrões, e como utilizar +parâmetros explícitos para evitar surpresas. + + ~/project$ git add hello.c + ~/project$ git commit -m "Utiliza world sem capitalização" + [master 18c7b69] Utiliza world sem capitalização + 1 file changed, 1 insertion(+), 1 deletion(-) + ~/project$ git push origin master:master + Counting objects: 3, done. + Delta compression using up to 4 threads. + Compressing objects: 100% (3/3), done. + Writing objects: 100% (3/3), 321 bytes | 0 bytes/s, done. + Total 3 (delta 2), reused 0 (delta 0) + To /home/user2/project + 033d4b8..18c7b69 master -> master + ~/project$ + +Adicionamos um novo commit ao nosso histórico, e fazemos uma atualização +no repositório remoto origin. O primeiro parâmetro é o repositório +remoto que queremos atualizar. O segundo parâmetro, chamado refspec, +especifica o branch local e o branch remoto que serão sincronizados. + +No exemplo acima, o branch local master foi utilizado para atualizar o +branch remoto master. Objetos são escritos no repositório remoto, e a +referência atualizada. + +Note que o branch de origem deve conter todos os commits no branch de +destino a ser atualizado. Caso contrário, o push não avançará o branch +remoto, o que chamamos de fast-forward. Veremos mais à frente as +condições para termos uma situação de fast-forward. + +Tanto o remoto quanto o refspec podem ser omitidos. O padrão em versões +anteriores à versão 2.0.0 do Git era fazer o push de todos os branches +com nomes iguais ao repositório remoto especificado explicitamente ou +implicitamente. Se o remoto não é especificado, é assumido o remoto que +o branch corrente rastreia. + +No exemplo sobre Branches remotos acima, o branch local shell rastreia o +branch remoto alice/shell. Caso este branch seja o branch corrente, git +push utilizaria por padrão o repositório remoto alice. O refspec +matching, como é chamado o padrão utilizado em versões anteriores à Git +2.0.0, atualizaria todos os branches no remoto alice que tivessem um +branch local com o mesmo nome. Ou seja, se alice tivesse branches +master, devel e shell, e estes mesmos branches existissem localmente, +todos seriam atualizados. Ainda que o branch local master rastreasse o +branch remoto origin/master, alice/master seria atualizado neste caso +específico. Se o branch corrente fosse master, que rastreasse +origin/master, o repositório remoto origin seria atualizado no lugar do +repositório remoto alice. + +O novo padrão, a partir da versão 2.0.0, se chama simple. Ele atualiza +apenas o branch atual, apenas se o branch remoto rastreado tiver o mesmo +nome. + +As outras opções, sendo todas elas configuráveis globalmente ou por +repositório, através da opção push.default, são upstream, current e +nothing. A opção nothing exige que o refspec esteja explícito na linha +de comando. A opção current atualiza no remoto especificado ou ímplicito +o branch com o mesmo nome que o branch local corrente. E a opção +upstream atualiza o branch remoto rastreado pelo branch corrente. + ## Publicando um repositório + +Vimos como trabalhar com um repositório remoto, obtendo seus commits +para trablharmos localmente. No entanto, o caminho reverso é necessário +para publicarmos os commits locais para que outros possam trabalhar com +eles. + +Há várias formas de fazê-lo. Veremos aqui algumas delas, utilizando um +host próprio, que seja acessível ao público alvo, através de SSH, HTTP +ou git daemon. + +Publicar através de SSH é simples de ser feito, mas tem algumas +implicações. Entre elas é o acesso exigido a um shell no host para os +usuários, dificultando acesso anônimo e criando um novo problema de +segurança a ser resolvido. A outra implicação é que o acesso por +múltiplos usuários a um mesmo repositório exige um cuidado especial para +evitar problemas de permissão quando um usuário publica novos commits e +outros objetos. Há algumas soluções que resolvem alguns desses +problemas, criando um shell e um usuário especial para uso dedicado a +repositórios Git. Veremos, no entanto, apenas a solução mais comum, que +não exige outro software instalado no host, além de Git. + +Uma excelente forma de utilizar a publicação via SSH é disponibilizá-la +de forma somente leitura através de outros métodos, e ter um único +usuário que possa atualizá-lo, o que resolve vários dos problemas já +mencionados.