5.1 Git Distribuído - Fluxos de Trabalho Distribuídos

Em sistemas centralizados, geralmente há um único modelo de colaboração — o fluxo de trabalho centralizado. Um hub central, ou repositório, pode aceitar código, e todos sincronizam o seu trabalho com ele. Um número de desenvolvedores são nós — consumidores daquele hub — e sincronizam com esse local centralizado.

Isso significa que, se dois desenvolvedores clonarem do hub e ambos fizerem alterações, o primeiro desenvolvedor a fazer o push das suas alterações de volta pode fazê-lo sem problemas. O segundo desenvolvedor deve fazer o merge do trabalho do primeiro antes de fazer o push das alterações, para não substituir as alterações do primeiro desenvolvedor. Esse conceito é tão verdadeiro no Git quanto no Subversion (ou em qualquer CVCS), e esse modelo funciona perfeitamente bem no Git.

Se você já estiver confortável com um fluxo de trabalho centralizado na sua empresa ou equipe, poderá continuar usando esse fluxo de trabalho com o Git facilmente. Basta configurar um único repositório e dar acesso de push a todos na sua equipe; o Git não permitirá que os usuários sobrescrevam os trabalhos uns dos outros.

Digamos que John e Jessica comecem a trabalhar ao mesmo tempo. John termina a sua alteração e faz o push para o servidor. Então, Jessica tenta fazer o push de suas alterações, mas o servidor as rejeita. Ela é informada de que está tentando fazer um push de alterações non-fast-forward e que não conseguirá fazê-lo até fazer o fetch e o merge. Este fluxo de trabalho é atraente para muitas pessoas porque é um paradigma com o qual muitos estão familiarizados e confortáveis.

Isso também não se limita a equipes pequenas. Com o modelo de ramificação (branching model) do Git, é possível que centenas de desenvolvedores trabalhem com sucesso em um único projeto através de dezenas de branches simultaneamente.

Como o Git permite que você tenha vários repositórios remotos, é possível ter um fluxo de trabalho em que cada desenvolvedor tem acesso de gravação ao seu próprio repositório público e acesso de leitura aos de todos os outros. Esse cenário geralmente inclui um repositório canônico que representa o projeto “oficial”. Para contribuir com esse projeto, você cria o seu próprio clone público do projeto e faz o push das suas alterações para ele. Então, você pode enviar uma solicitação ao mantenedor do projeto principal para fazer o pull das suas alterações. O mantenedor pode então adicionar o seu repositório como remoto, testar as suas alterações localmente, mesclá-las no branch dele e fazer o push de volta para o repositório dele. O processo funciona da seguinte forma (veja Fluxo de trabalho do Gerente de Integração (Integration-manager)):

Este é um fluxo de trabalho muito comum com ferramentas baseadas em hub como o GitHub ou GitLab, onde é fácil fazer um fork de um projeto e fazer o push das suas alterações para o seu fork para que todos vejam. Uma das principais vantagens dessa abordagem é que você pode continuar a trabalhar, e o mantenedor do repositório principal pode fazer o pull das suas alterações a qualquer momento. Os contribuidores não precisam esperar que o projeto incorpore as suas alterações — cada parte pode trabalhar no seu próprio ritmo.

Esta é uma variante de um fluxo de trabalho de múltiplos repositórios. Geralmente é usado por projetos enormes com centenas de colaboradores; um exemplo famoso é o kernel do Linux. Vários gerentes de integração são responsáveis por certas partes do repositório; eles são chamados de tenentes (lieutenants). Todos os tenentes têm um gerente de integração conhecido como o ditador benevolente (benevolent dictator). O ditador benevolente faz o push do seu diretório para um repositório de referência do qual todos os colaboradores precisam fazer o pull. O processo funciona assim (veja Fluxo de trabalho do ditador benevolente (Benevolent dictator)):

Esse tipo de fluxo de trabalho não é comum, mas pode ser útil em projetos muito grandes ou em ambientes altamente hierárquicos. Ele permite que o líder do projeto (o ditador) delegue grande parte do trabalho e colete grandes subconjuntos de código em vários pontos antes de integrá-los.

Estes são alguns fluxos de trabalho comumente usados que são possíveis com um sistema distribuído como o Git, mas você pode ver que muitas variações são possíveis para se adequar ao seu fluxo de trabalho particular do mundo real. Agora que você pode (esperamos) determinar qual combinação de fluxo de trabalho pode funcionar para você, abordaremos alguns exemplos mais específicos de como cumprir os papéis principais que compõem os diferentes fluxos. Na próxima seção, você aprenderá sobre alguns padrões comuns para contribuir com um projeto.