Desenvolvimento

15 out, 2012

Dica GIT da Semana: fork e pull versus push

Publicidade

A dica Git desta semana é sobre a geração de GitHub.

Os sistemas de controle de versão distribuídos realmente decolaram nos últimos anos, embora estejam por aí por mais de uma década. É provável que o maior surto de crescimento tenha acontecido por causa da controvérsia que lançou o Git de volta em abril de 2005, proporcionando um sistema de controle de versão distribuído robusto, modelado em um sistema de arquivos. Em apenas alguns meses, o Git começou a hospedar a fonte do Linux. kernel 2.6.12.

No entanto, o Git não era tão popular até o nascimento do GitHub. Foi aí, de fato, que o Git realmente decolou. Fundado em fevereiro de 2008, o GitHub trouxe o Git para um público muito mais amplo e desde um site de hospedagem gratuita, para repositórios Git públicos (assim como os planos comerciais para repositórios privados). Tem sido argumentado que GitHub é uma das razões pelas quais o Git decolou mais rápido do que outros, como Hg e Bzr.

O que o GitHub trouxe foi o foco em um novo modelo, ao invés de criar patches (conforme abordado antes), o GitHub incentivou a realização do fork universal do repositório. Então, se você quiser adicionar uma mudança para um repositório existente, você pode fazer um fork nele (e criar o seu próprio clone), fazer as alterações e depois enviar uma solicitação de recebimento.

Não há nada de significativo sobre solicitações pull no fluxo de trabalho Git, em comparação a outras ferramentas DVCS. Push e pul são duas chaves primárias em um fluxo de trabalho DVCS, afinal. Mas o que era uma novela sobre abordagem do GitHub, foi a maneira encontrada para que as solicitações de pull pudessem ser enviadas, como uma mensagem out-of-band para o proprietário do repositório montante sugerindo a ideia.

Não só isso, mas o proprietário upstream, então, receberá uma notificação e poderá ver o pedido no lugar, e com os diffs apropriados (fora de uma correspondência de um cliente, por meio da interface da web). Os avanços subsequentes, tais como a capacidade de realizar o fork para consertar erros/ enganos, significavam que alguém poderia sugerir mudanças pela web, mesmo sem a necessidade de compilar o código localmente.

Pushing, pulling, patching, ou proposing

Como resultado, os repositórios Git podem acabar com os fluxos de trabalho diferentes, dependendo do tipo de projeto e ambiente de hospedagem que você está usando. São eles:

  • Pushing: Você tem acesso para escrever diretamente no repositório, então você só realiza o push em suas alterações;
  • Pulling: Alguém possui alterações locais e te pede para que você faça oum pulln a mudança de seu repositório;
  • Patching: Você envia os diffs/patches por um mecanismo de transporte (bugzilla, e-mail) para análise;
  • Proposing: Você usa uma ferramenta como Gerrit para propor alterações que podem sofrer um merge posteriormente.

Cada projeto possui um estilo diferente de operação em potencial e não há um jeito “certo” de usar um repositório Git. O GitHub, por exemplo, favorece fortemente o modelo pull quando o consumo muda a partir de outros (embora, naturalmente, o proprietário do repositório possa fazer um push diretamente). O Kernel do Linux, tanto por razões históricas, quanto por discussões abertas e de transparência, escolhe o patch (por e-mail) do modelo.

O último – proposing – é uma combinação do push, pull, e dos modelos patch. Eles são semelhantes ao mecanismo pull do GitHub, em que os donos do projeto podem ver uma lista de todas as alterações de entrada e decidir quais usar, mas o upload baseado em push significa que o repositório original não tem que sofrer um fork no servidor remoto. E, finalmente, as ferramentas como Gerrit podem ser utilizadas para gerar patches, discussões e até mesmo agir como um repositório Git para consumir pelos protocolos padrões git fetch.

A abordagem do GitHub de baseado em pull teve certamente um grande impacto sobre o número de usuários dispostos a tentar esse método. Eles têm uma nota sobre os modelos de desenvolvimento colaborativo:

O modelo Fork + Pull permite que qualquer um faça um fork em um repositório existente e realize um push nas alterações para o seu fork pessoal. Este modelo reduz a quantidade de atrito para novos colaboradores e é popular com projetos de código aberto, pois permite as pessoas trabalharem de forma independente sem uma coordenação inicial.
O modelo de repositório compartilhado prevalece em equipes pequenas e organizações que colaboram em projetos privados. É dado a todos o acesso ao push para um único repositório compartilhado e tópicos branches são usados para isolar as alterações.

Certamente, se existem pequenas alterações (como um erro na documentação) o modelo fork-e-pull, quando combinado com uma interface baseada na web, pode tornar as coisas mais fáceis para os contribuintes. Ao invés de ter a necessidade de criar contas nos sistemas de acompanhamento de falhas (ou ferramentas como o Gerrit), o repositório pode sofrer um for fixo e uma requisição pull, que seria disparada para os mantenedores do repositório. Com o botão de meger no GitHub que muitas vezes pode ser o caso de permitir que a correção sofra um merge sem o mantenedor ter que verificar o código. Reduzir a barreira para aceitar as mudanças ajuda a manter um projeto open-source ativo e aberto a todos.

O único problema com o modelo Fork + Pull é ele ser capaz de atribuir mudanças pelo usuário. Por exemplo, algumas fundações open-source querem garantir que as alterações sejam concedidas contra uma licença de código aberto existente (Apache ou Eclipse, por exemplo). Outros projetos tendem a não ser tão rigorosos e aceitam alegremente as contribuições de qualquer um, com o pressuposto de que todo contribuinte concorda com a licença. Um serviço adicional ‘patches para bugzilla’, ou ‘push gerrit’ fornece a aceitação de um acordo de contribuição, o que normalmente indica que o indivíduo tem o direito de conceder o código sob a licença específica. Um dos efeitos colaterais da criação de uma conta, é que muitas vezes implica (explícita ou implicitamente) em um acordo para que as regras acompanhem as regras de licenciamento da fundação.

Então, não há nenhuma maneira “certa” de fazer Git; equipes diferentes, as fundações e os projetos terão sua própria preferência para trabalhar com uma estratégia particular, e podem evoluir ao longo do tempo. Ao invés, é bom conhecer o que está disponível, de modo que a escolha certa para que o projeto possa ser feita, entendendo os fluxos diferentes disponíveis.

***

Artigo original disponível em: http://alblue.bandlem.com/2011/12/git-tip-of-week-forking-and-pulling-vs.html