![Fechar [x]](http://dw1.s81c.com/i/c.gif){kind=small}
Os desenvolvedores de software têm estado entre os primeiros adeptos das redes sociais, portanto, é de se esperar que as redes estejam surgindo para atender ao universo especial da colaboração entre desenvolvedores, especialmente desenvolvedores de software livre. Há muito tempo, o universo de software livre possui serviços populares de hosting para projetos, sendo o SourceForge o mais conhecido deles. Por muito tempo, eles foram desenvolvidos em larga escala sob os princípios da "Web 1.0", que se tornaram um pouco antiquados, enquanto tantos outros desenvolvimentos estavam revolucionando a maneira como as pessoas interagiam na web.
No núcleo da maioria dos sites de projeto de software livre estavam centralizados sistemas de gerenciamento de software livre (SCM), como o CVS e, posteriormente, o Subversion. Ao mesmo tempo, uma nova geração de SCMs estava emergindo, chamada de sistema de controle de versão (ou revisão) distribuída (ou descentralizada) (DVCS). A ideia principal do DVCS é que, em vez de ter uma árvore de origem central e canônica, você possua um sistema de diversas cópias em funcionamento. Isso significa que diversos desenvolvedores podem colaborar em um projeto, mesmo se estiverem conectados apenas esporadicamente.
As interações entre essas cópias distribuídas em funcionamento são um pouco remanescentes das interações entre pessoas nas redes sociais. Portanto, sites de hosting de projeto naturalmente cresceram em torno de conceitos de DVCS com recursos sociais de acordo com o modelo de compartilhamento de código. Alguns dos DVCS mais populares atualmente são Mercurial, Git e Bazaar, e cada um possui um serviço conhecido e intimamente associado, respectivamente, ao BitBucket, GitHub e Launchpad.
Neste artigo, conheça os sites de hosting de projeto baseados em recursos de redes sociais e DVCS, com ênfase no GitHub. O leitor deve ter alguma familiaridade com sistemas de controle de versão, mas não necessariamente o DVCS.
Noções básicas de colaboração no DVCS
Ao usar um DVCS para colaboração, um primeiro usuário (cujo nome será Alice) cria o repositório de código e, em seguida, o compartilha, talvez inicialmente com um colega, o Bob. A Alice pode compartilhar seu repositório com outros na mesma máquina ou propagar um disco de armazenamento, bem como por uma rede. Bob clona o repositório de Alice usando um programa de DVCS compatível e agora ele possui um repositório próprio, com base no código dela. O repositório de Bob começa com o mesmo conteúdo do de Alice, mas ele tem sua própria identidade e ciclo de vida. Essa é a principal distinção entre o DVCS e os repositórios centralizados.
A clonagem de um repositório é, na verdade, a bifurcação de um projeto, devido à identidade e ao ciclo de vida separados do novo repositório. Havia uma tendência para uma percepção negativa de bifurcação de projetos de software, em parte devido aos exemplos célebres de bifurcações que foram relacionadas a um colapso social de colaboração dentro de um projeto. Nesse exemplo, estava a cisma no Emacs, o editor de texto venerável e venerado e o sistema utilitário do programador. O projeto XEmacs tornou-se um projeto divisor de águas liderado pelos antigos e descontentes desenvolvedores do Emacs. O DVCS removeu o contexto social de bifurcação, tornando-o uma parte genérica do processo de colaboração. Certamente, se Bob e Alice tivessem uma briga e decidissem seguir caminhos separados no projeto, eles poderiam, em algum ponto, continuar a partir de uma bifurcação, mas eles também estariam propensos a usá-la como uma parte natural da sua cooperação.
Em particular, Bob e Alice podem querer fazer atualizações separadas de seus próprios repositórios; talvez Bob esteja trabalhando na interface com o usuário e Alice esteja trabalhando na principal lógica do programa. Em determinado momento, eles gostariam de se unir e combinar os frutos de seus trabalhos. Eles teriam acumulado changesets distintos em seus repositórios separados. Um changeset é uma coleção de atualizações para arquivos que foram registrados ao mesmo tempo emitindo um comando "commit" por meio do DVCS.
Em um sistema de controle de versão centralizado, changesets são compromissos com o repositório principal, identificado por números de revisão incrementais. O primeiro compromisso, realizado por Bob, pode ser a revisão 1.1; o segundo pode ser a 1.2; e assim por diante. Isso não faz sentido no caso do DVCS em que não há armazenador central e nenhuma maneira de gerenciar globalmente a ordem das mudanças; portanto, em vez disso, cada changeset recebe um hash, desenvolvido para ser exclusivo nos repositórios. Consulte a Figura 1 para obter uma ilustração da clonagem inicial e do progresso de changesets separados entre Bob e Alice. As estrelas marcam os pontos nos quais os repositórios de Bob e Alice possuem um estado idêntico (quando Bob clonou sua cópia inicial do código de Alice.)
Figura 1. Troca inicial com o DVCS
Quando Bob e Alice desejam combinar o seu trabalho, eles fazem isso trocando changesets e resolvendo quaisquer conflitos até que possam chegar a um novo repositório que representa o trabalho de ambos combinado da maneira como desejam. Para iniciar esse processo, Bob pode "realizar o pull" das mudanças do repositório de Alice ou vice-versa. Novamente, a maneira como isso acontecerá não importa e é puramente baseada nas circunstâncias de sua colaboração. É possível que a direção do "pull" entre Bob e Alice seja ocasionalmente alternada, talvez até mesmo por capricho.
Quando Bob "realiza o pull" de Alice, o DVCS será aplicável a cada changeset de Alice, para a versão local do Bob. É possível que changeset leve a um conflito, caso Bob e Alice tenham modificado a mesma linha em um arquivo em algum lugar ou caso Bob tenha atualizado um arquivo que Alice removeu de seu repositório. Em caso de conflito, o software DVCS pode ser capaz de descobrir uma fusão automática ou pode ser necessária uma intervenção de Bob para trabalhar no resultado da fusão.
Quando Bob tiver realizado o pull dos changesets de Alice, ele poderá realizar o push do resultado mesclado para Alice. O DVCS processará os changesets de Bob a partir do ponto de fusão mais recente e reconhecerá que alguns desses changesets são da própria Alice, que já foram aplicados ao repositório do Bob. Os hashes exclusivos são importantes aqui para descobrir a identidade dos changesets nesse processo. Quando o push estiver concluído, Alice e Bob terão o mesmo conteúdo em cada um de seus repositórios. Consulte a Figura 2 para obter uma ilustração do processo de pull/fusão/push. Observe que isso leva a um estado novo e compartilhado entre Bob e Alice.
Figura 2. Fazendo a fusão de changesets com DVCS
Este processo possui muitas variações e sutilezas, algumas são exclusivas de determinadas implementações de DVCS, mas tocarei em apenas um dos problemas mais comuns enfrentado pelos novos usuários de DVCS.
Suponhamos que, no processo acima, Bob se esqueça de realizar o pull das mudanças de Alice antes de realizar o push das dele próprio para o repositório dela. Nesse caso, o software DVCS avisará que Bob fez a ramificação a partir do último ponto de fusão com o repositório de Alice. Um dos princípios fundamentais de DVCS é que um changeset é aplicado apenas a um estado inicial conhecido do ponto do repositório, chamado de pai comum. Como os changesets de Bob existem com relação ao pai comum de quando ele fez a primeira clonagem da Alice, o DVCS, na verdade, voltaria àquele estado, antes da aplicação desses changesets. Isso teria o efeito de colocar os changesets de Alice a partir do pai comum em uma ramificação separada, o que geralmente não é o que Bob ou Alice desejam. Em geral, em casos como esse, o DVCS emite um aviso sobre a operação de push de criar "diversos cabeçotes". Bob pode interromper o push e, em seguida, realizar o pull de Alice, fundindo-se aos changesets de Alice, na mesma ramificação que os dele. O resultado do pull é uma única ramificação que contém os changesets de Bob e Alice a partir de um pai comum. Nesse estado, Bob pode realizar o push para a Alice sem ter o problema de "diversos cabeçotes".
Implicações sociais de interações básicas de DVCS
O DVCS fornece uma grande flexibilidade ao processo, mas os projetos devem sobrepor algum fluxo de trabalho mais amplo no uso básico, especialmente à medida que cada vez mais pessoas são envolvidas, com funções e níveis de interação diferentes. Geralmente, haverá um repositório reconhecido que começa a assumir um pouco da essência do antigo repositório centralizado, mas só por acaso. A bifurcação é tão fácil e normal quanto, e, normalmente, existem inúmeros repositórios espalhados entre aqueles com algum interesse no projeto; é somente por convenção que os participantes evitam o caos. Esse é o caso especialmente em projetos de software livre, nos quais qualquer pessoa tem permissão para clonar ou realizar o pull do repositório principal. O(s) líder(es) do projeto irá(ão) identificar seu repositório principal e dará(ão) permissão aos colaboradores confiáveis para realizarem o pull das mudanças.
Em um projeto de software livre com bom funcionamento, nem todos os contribuidores tendem a ser colaboradores confiáveis. Os sites de hosting de projeto mais clássicos possuíam rastreadores de correção para lidarem com rastreadores de problema. Qualquer pessoa pode submeter uma correção a um projeto, que é, então, controlada enquanto um desenvolvedor principal a examina e, talvez, interaja com o requisitante para fazer mudanças. Posteriormente, a correção pode ser aplicada ao principal repositório de projeto.
Devido à natureza do DVCS e ao gerenciamento cuidadoso de changesets, existe uma oportunidade para melhorar um pouco o processo. Em particular, o antigo sistema de envio de correção geralmente perde o histórico particular de mudanças que levaram à correção. Com o DVCS, o contribuidor pode realizar o pull de um repositório principal, desenvolver suas mudanças em seu repositório em funcionamento, confirmando como sempre e, em seguida, enviar os changesets resultantes para revisão e discussão. Esse processo se tornou conhecido como uma solicitação de pull. Na realidade, o contribuidor está solicitando que um desenvolvedor principal realize o pull do repositório em funcionamento com as mudanças propostas e, após a discussão, refine as mudanças e realize o push desses changesets para o repositório principal.
Em sistemas como GitHub, o recurso de solicitação de pull (consulte Recursos) é uma questão de colocar uma interface conveniente no fluxo de trabalho de nomeação de um repositório para iniciar uma solicitação de pull, discutindo as mudanças propostas e, em seguida, aplicando os changesets resultantes a um repositório de destino.
Nenhuma rede social está completa se não houver algum sistema para que as pessoas sigam outras, o que resulta em uma disputa por popularidade. Os principais sites de DVCS não são diferentes. É possível optar por seguir um desenvolvedor ou um projeto, caso se interesse pelos projetos dele; o desenvolvedor é, então, notificado disso e pode optar por seguir ou não você. O vocabulário pode variar, por exemplo, no GitHub, você "segue" uma pessoa, mas "assiste a" um projeto; no entanto, o conceito é parecido com o adotado no Twitter e Facebook, com uma dinâmica social semelhante. Por exemplo, surgem impressões sobre a influência de um desenvolvedor ou o bom andamento de um projeto a partir da contagem dos seguidores e isso pode desempenhar um papel na dinâmica social que pode sobrepor o DVCS, como quais ramificações "ganham" em uma bifurcação ruim.
O software livre tem crescido cada vez mais e se tornou uma parte muito significativa do cenário tecnológico mundial. Esse crescimento foi resultado de trabalho duro, mas também de personalidades e apoio. Gostaria de poder dizer que, em redes sociais que procuram incorporar o processo de colaboração de software livre, esse código tem a sua influência e tudo o mais é secundário. Infelizmente, não é possível retirar o social de uma rede social. Caso se envolva com sites, como o GitHub, seguindo o seu interesse em redes sociais, seja como usuário, contribuidor de um projeto ou líder de seu próprio projeto, é importante compreender o fluxo de trabalho do utilitário subjacente, mas também as implicações e os subentendidos sociais que caminham lado a lado com a troca de bits.
As sugestões habituais são aplicáveis às redes sociais: comunicar-se com as pessoas como se estivesse cara a cara com ela, ser resistente e estar pronto para se livrar de conflitos pessoais improdutivos e, acima de tudo, produzir o seu melhor código, o que atrairá seguidores e até mesmo colaboradores. Sites como o GitHub facilitam um início mais lento antes que você talvez possa colaborar mais intensamente em grandes projetos. Espero que este artigo ajude a começar a compreender a geração emergente de sites de hosting de projetos.
Aprender
- Saiba mais sobre as solicitações de pull no GitHub e
BitBucket.
- Leia esta introdução fácil e baseada em Mercurial aos princípios de DVCS.
- Saiba mais sobre as ferramentas de linha de comandos Git DVCS em Manage source code using Git (Eli M. Dow, developerWorks, julho de 2006).
- Saiba mais sobre as ferramentas de linha de comandos Mercurial DVCS em Managing source code with Mercurial (William von Hagen, developerWorks, agosto de 2011).
- Saiba mais sobre como usar o Git no desenvolvimento da web em Git changes the game of distributed Web development (William von Hagen, developerWorks, agosto de 2009).
- No menu suspenso Software Livre, no developerWorks, encontre amplas informações instrutivas, ferramentas e atualizações de projeto para ajudá-lo a desenvolver com tecnologias de software livre e usá-las com produtos IBM.
- No menu suspenso zona Linux do developerWorks, encontre vários artigos de instruções e tutoriais, bem como downloads, fóruns de discussão e muitos outros recursos para desenvolvedores e administradores Linux.
- Fique por dentro dosEventos técnicos e webcasts do developerWorks com ênfase em uma série de produtos IBM e tópicos do segmento de mercado de TI.
- Participe de um briefing gratuito do developerWorks para atualizar-se rapidamente sobre produtos e ferramentas IBM e tendências do segmento de mercado de TI.
- Escute os Podcasts do developerWorks para obter entrevistas interessantes e
discussões para os desenvolvedores de software.
- Siga o developerWorks no Twitter.
- Acompanhe as Demos do developerWorks que vão desde instalação e configuração de produtos para iniciantes até funcionalidades avançadas para desenvolvedores experientes.
Obter produtos e tecnologias
- GitHub é um site de hosting de projeto popular em que os repositórios de código são gerenciados usando o Sistema de controle de versão Git DVCS.
- BitBucket é um site de hosting de projeto intimamente associado ao Mercurial DVCS, mas que também oferece suporte ao Git.
- Acesseversão de teste do software IBM (disponível para download ou em DVD) e inove em seu próximo projeto de desenvolvimento de software livre próprio usando o software especialmente para desenvolvedores.
Discutir
- Conecte-se com outros usuários do
developerWorks enquanto explora os blogs, fóruns, grupos e wikis voltados para desenvolvedores. Ajude a desenvolver o software livre do mundo real na comunidade do developerWorks.
Uche Ogbuji é sócio da Zepheira , onde supervisiona a criação de sofisticados catálogos da web e outros bancos de dados ricamente contextuais. Ele possui uma longa história de pioneirismo em tecnologias avançadas da web, como XML, web semântica e serviços da web e projetos de software livre como Akara, uma plataforma de software livre para aplicativos de dados da web. É engenheiro da computação e escritor nascido na Nigéria que mora e trabalha perto de Boulder, Colorado, EUA. Você encontra mais informações sobre o Sr. Ogbuji no seu blog, Copia.
