A Git Workflow é uma receita ou recomendação de como usar Git para realizar o trabalho de uma forma consistente e produtiva. Os fluxos de trabalho de Git encorajam os utilizadores a tirar partido de Git de forma eficaz e consistente. Git oferece uma grande flexibilidade na forma como os utilizadores gerem as mudanças. Dado o foco de Git na flexibilidade, não existe um processo padronizado sobre como interagir com Git. Ao trabalhar com uma equipa num projecto gerido por Git, é importante assegurar que a equipa está de acordo sobre como o fluxo de mudanças será aplicado. Para assegurar que a equipa está na mesma página, deve ser desenvolvido ou seleccionado um fluxo de trabalho de Git acordado. Existem vários fluxos de trabalho publicitados de Git que podem ser um bom ajuste para a sua equipa. Aqui, iremos discutir algumas destas opções de fluxo de trabalho.

O conjunto de possíveis fluxos de trabalho pode tornar difícil saber por onde começar ao implementar Git no local de trabalho. Esta página fornece um ponto de partida através do levantamento dos fluxos de trabalho de Git mais comuns para as equipas de software.

Ao ler, lembre-se que estes fluxos de trabalho são concebidos para serem directrizes e não regras concretas. Queremos mostrar-lhe o que é possível, para que possa misturar e combinar aspectos de diferentes fluxos de trabalho de acordo com as suas necessidades individuais.

O que é um fluxo de trabalho de Git bem sucedido?

Ao avaliar um fluxo de trabalho para a sua equipa, é mais importante que considere a cultura da sua equipa. Quer que o fluxo de trabalho aumente a eficácia da sua equipa e não seja um fardo que limite a produtividade. Algumas coisas a considerar ao avaliar um fluxo de trabalho Git são:

• Faz esta escala de fluxo de trabalho com o tamanho da equipa?
• É fácil desfazer erros e erros com este fluxo de trabalho?
• Este fluxo de trabalho impõe alguma nova sobrecarga cognitiva desnecessária à equipa?

Workflow Centralizado

p> O Workflow Centralizado é um grande workflow Git para equipas em transição do SVN. Tal como o Subversion, o Workflow Centralizado utiliza um repositório central para servir como ponto de entrada único para todas as alterações ao projecto. Em vez detrunk, o ramo de desenvolvimento padrão chama-semastere todas as alterações são cometidas neste ramo. Este fluxo de trabalho não requer qualquer outro ramo para além demaster.

Transição para um sistema de controlo de versões distribuído pode parecer uma tarefa assustadora, mas não é necessário alterar o fluxo de trabalho existente para tirar partido de Git. A sua equipa pode desenvolver projectos exactamente da mesma forma que faz com Subversion.

No entanto, a utilização de Git para alimentar o seu fluxo de trabalho de desenvolvimento apresenta algumas vantagens sobre o SVN. Primeiro, dá a cada desenvolvedor a sua própria cópia local de todo o projecto. Este ambiente isolado permite a cada programador trabalhar independentemente de todas as outras alterações a um projecto – eles podem adicionar compromissos ao seu repositório local e esquecer completamente os desenvolvimentos a montante até lhes ser conveniente.

Segundo, dá-lhe acesso ao robusto modelo de ramificação e fusão de Git. Ao contrário do SVN, os ramos de Git são concebidos para serem um mecanismo à prova de falhas para integrar código e partilhar alterações entre os repositórios. O fluxo de trabalho centralizado é semelhante a outros fluxos de trabalho na sua utilização de um repositório remoto hospedado do lado do servidor que os programadores empurram e puxam. Comparado com outros fluxos de trabalho, o Fluxo de Trabalho Centralizado não tem um pedido definido de puxar ou padrões de forking. Um Fluxo de Trabalho Centralizado é geralmente mais adequado para equipas que migram de SVN para Git e equipas de menor dimensão.

Como funciona

Desenvolvedores começam por clonar o repositório central. Nas suas próprias cópias locais do projecto, eles editam os ficheiros e submetem as alterações como fariam com o SVN; no entanto, estes novos commits são armazenados localmente – eles estão completamente isolados do repositório central. Isto permite aos programadores adiar a sincronização a montante até estarem num ponto de interrupção conveniente.

Para publicar alterações ao projecto oficial, os programadores “empurram” o seu master ramificam para o repositório central. Isto é o equivalente a svn commit, excepto que adiciona todos os compromissos locais que ainda não estão no central master branch.

Inicializar o repositório central

p>First, alguém precisa de criar o repositório central num servidor. Se for um novo projecto, é possível inicializar um repositório vazio. Caso contrário, terá de importar um repositório Git ou SVN existente.

Repositórios centrais devem ser sempre repositórios vazios (não devem ter um directório de trabalho), que podem ser criados da seguinte forma:

ssh user@host git init --bare /path/to/repo.git

Não se esqueça de usar um nome de utilizador SSH válido para user, o domínio ou endereço IP do seu servidor para host, e o local onde gostaria de armazenar o seu repo para /path/to/repo.git. Note que a extensão .git é convencionalmente anexada ao nome do repositório para indicar que é um repositório vazio.

Repositórios centrais alojados

Repositórios centrais são frequentemente criados através de serviços de alojamento Git de terceiros como Bitbucket Cloud ou Bitbucket Server. O processo de inicialização de um repositório nu discutido acima é tratado para si pelo serviço de alojamento. O serviço de alojamento irá então fornecer um endereço para o repositório central aceder a partir do seu repositório local.

Clonar o repositório central

Next, cada desenvolvedor cria uma cópia local de todo o projecto. Isto é realizado através do comando git clone comando:

git clone ssh://user@host/path/to/repo.git

Quando se clona um repositório, Git adiciona automaticamente um atalho chamado origin que aponta de volta ao repositório “pai”, sob a suposição de que se quererá interagir com ele mais à frente.

Fazer alterações e submeter

Após o repositório ser clonado localmente, um programador pode fazer alterações utilizando o processo padrão de submissão Git: editar, encenar, e submeter. Se não estiver familiarizado com a área de encenação, é uma forma de preparar um commit sem ter de incluir todas as alterações no directório de trabalho. Isto permite-lhe criar commits altamente focalizados, mesmo que tenha feito muitas alterações locais.

git status # View the state of the repo git add # Stage a file git commit # Commit a file

Lembra-te que, uma vez que estes comandos criam commits locais, John pode repetir este processo quantas vezes quiser sem se preocupar com o que está a acontecer no repositório central. Isto pode ser muito útil para grandes características que precisam de ser decompostas em pedaços mais simples e atómicos.

Push new commits to central repository

A partir do momento em que o repositório local tenha novas alterações comprometidas. Estas alterações terão de ser empurradas para partilhar com outros programadores no projecto.

git push origin master

Este comando empurrará as novas alterações comprometidas para o repositório central. Ao empurrar as alterações ao repositório central, é possível que tenham sido empurradas anteriormente actualizações de outro programador que contenham código que entre em conflito com as actualizações pretendidas. Git irá emitir uma mensagem indicando este conflito. Nesta situação, git pull terá primeiro de ser executado. Este cenário de conflito será expandido na secção seguinte.

Gestão de conflitos

O repositório central representa o projecto oficial, pelo que a sua história de compromisso deve ser tratada como sagrada e imutável. Se os commits locais de um programador divergirem do repositório central, Git recusar-se-á a pressionar as suas alterações, porque isto substituiria os commits oficiais.

p> Antes que o programador possa publicar a sua funcionalidade, ele precisa de ir buscar os commits centrais actualizados e rebasear as suas alterações em cima deles. Isto é como dizer: “Quero acrescentar as minhas alterações ao que todos os outros já fizeram”. O resultado é uma história perfeitamente linear, tal como nos fluxos de trabalho tradicionais do SVN.

Se as alterações locais entrarem em conflito directo com os commits a montante, Git fará uma pausa no processo de rebaseamento e dar-lhe-á uma oportunidade de resolver manualmente os conflitos. O bom de Git é que usa os mesmos git status e git add comandos tanto para gerar commits como para resolver conflitos de fusão. Isto facilita aos novos criadores a gestão das suas próprias fusões. Além disso, se eles se meterem em problemas, Git torna muito fácil abortar todo o rebase e tentar novamente (ou ir procurar ajuda).

Exemplo

Vamos dar um exemplo geral de como uma pequena equipa típica colaboraria utilizando este fluxo de trabalho. Veremos como dois criadores, John e Mary, podem trabalhar em funcionalidades separadas e partilhar as suas contribuições através de um repositório centralizado.

John trabalha na sua funcionalidade

p> No seu repositório local, John pode desenvolver funcionalidades usando o processo padrão de commit Git: edit, stage, and commit.

p>Remmbrar que uma vez que estes comandos criam commits locais, John pode repetir este processo tantas vezes quantas quiser sem se preocupar com o que se passa no repositório central.

Mary trabalha na sua funcionalidade

p>Meanwhile, Mary está a trabalhar na sua própria funcionalidade no seu próprio repositório local usando o mesmo processo de edição/estágio/compromisso. Tal como John, ela não se importa com o que se passa no repositório central, e ela realmente não se importa com o que John está a fazer no seu repositório local, uma vez que todos os repositórios locais são privados.

John publica a sua funcionalidade

p>Once John termina a sua funcionalidade, ele deve publicar os seus compromissos locais no repositório central para que outros membros da equipa possam aceder ao mesmo. Ele pode fazê-lo com o comandogit push, como so:

git push origin master

Lembra-te que origin é a ligação remota ao repositório central que Git criou quando John o clonou. O argumento master diz a Git para tentar fazer com que o origin‘s master se pareça com o seu ramo local master ramo. Uma vez que o repositório central não foi actualizado desde que John o clonou, isto não resultará em quaisquer conflitos e o empurrão funcionará como esperado.

Mary tenta publicar a sua característica

Vejamos o que acontece se Mary tentar publicar a sua funcionalidade depois de John ter publicado com sucesso as suas alterações no repositório central. Ela pode usar exactamente o mesmo comando push:

git push origin master

Mas, uma vez que a sua história local divergiu do repositório central, Git recusará o pedido com uma mensagem de erro bastante verbosa:

error: failed to push some refs to '/path/to/repo.git' hint: Updates were rejected because the tip of your current branch is behind hint: its remote counterpart. Merge the remote changes (e.g. 'git pull') hint: before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details.

Isto impede Maria de escrever por cima dos compromissos oficiais. Ela precisa de puxar as actualizações de John para o seu repositório, integrá-las com as suas alterações locais, e depois tentar novamente.

Mary rebase em cima do(s)commit(s)

Mary pode usar git pull para incorporar as alterações a montante no seu repositório. Este comando é como svn update-trai todo o histórico de commit upstream para o repositório local de Mary e tenta integrá-lo com os seus commits locais:

git pull --rebase origin master

O --rebase opção diz a Git para mover todos os commits de Mary para a ponta do master ramo depois de o sincronizar com as alterações do repositório central, como mostrado abaixo:

O pull ainda funcionaria se se esquecesse desta opção, mas acabaria com um supérfluo “compromisso de fusão” sempre que alguém precisasse de sincronizar com o repositório central. Para este fluxo de trabalho, é sempre melhor rebasear em vez de gerar um commit.

Mary resolve um conflito de merge

p>Trabalhos de Rebase transferindo cada commit local para o updatemasterramo um de cada vez. Isto significa que se apanham conflitos de fusão numa base de compromisso por compromisso em vez de resolver todos eles num único compromisso de fusão maciça. Isto mantém os seus compromissos tão focalizados quanto possível e faz com que a história do projecto seja limpa. Por sua vez, isto torna muito mais fácil descobrir onde os bugs foram introduzidos e, se necessário, reverter as alterações com um impacto mínimo no projecto.

Se Mary e John estão a trabalhar em características não relacionadas, é improvável que o processo de rebase gere conflitos. Mas se o fizer, Git fará uma pausa na rebase no actual compromisso e emitirá a seguinte mensagem, juntamente com algumas instruções relevantes:

CONFLICT (content): Merge conflict in 

p> A grande coisa sobre Git é que qualquer pessoa pode resolver os seus próprios conflitos de fusão. No nosso exemplo, Mary simplesmente executaria umgit statuspara ver onde está o problema. Os ficheiros conflituosos aparecerão na secção Caminhos não fundidos:

# Unmerged paths: # (use "git reset HEAD ..." to unstage) # (use "git add/rm ..." as appropriate to mark resolution) # # both modified: 

Então, ela editará o(s) ficheiro(s) ao seu gosto. Uma vez satisfeito com o resultado, ela pode encenar o(s) ficheiro(s) da forma habitual e deixar git rebase fazer o resto:

git add git rebase --continue

E é tudo o que há para fazer. Git passará ao próximo compromisso e repetirá o processo para quaisquer outros compromissos que gerem conflitos.

Se chegar a este ponto e perceber e não tiver ideia do que se está a passar, não entre em pânico. Basta executar o seguinte comando e estará de volta ao ponto de partida:

git rebase --abort

Mary publica com sucesso a sua funcionalidade

Depois de ter feito a sincronização com o repositório central, Mary poderá publicar as suas alterações com sucesso:

git push origin master

Where to go from here

Como pode ver, é possível replicar um ambiente de desenvolvimento tradicional Subversion usando apenas um punhado de comandos Git. Isto é óptimo para a transição de equipas fora do SVN, mas não potencia a natureza distribuída de Git.

O fluxo de trabalho centralizado é óptimo para equipas pequenas. O processo de resolução de conflitos detalhado acima pode formar um estrangulamento à medida que a sua equipa se dimensiona em tamanho. Se a sua equipa se sente confortável com o Fluxo de Trabalho Centralizado, mas quer racionalizar os seus esforços de colaboração, vale definitivamente a pena explorar os benefícios do Fluxo de Trabalho de Ramo em Destaque. Dedicando um ramo isolado a cada característica, é possível iniciar discussões aprofundadas em torno de novas adições antes de as integrar no projecto oficial.

Outros fluxos de trabalho comuns

O Fluxo de Trabalho Centralizado é essencialmente um bloco de construção para outros fluxos de trabalho Git. A maioria dos fluxos de trabalho populares de Git terá algum tipo de reporte centralizado do qual os programadores individuais irão empurrar e puxar. Abaixo discutiremos brevemente alguns outros fluxos de trabalho populares de Git. Estes fluxos de trabalho alargados oferecem padrões mais especializados no que diz respeito à gestão de ramificações para desenvolvimento de características, correcções a quente, e eventual lançamento.

Ramificação de características

A Ramificação de características é uma extensão lógica do Fluxo de trabalho centralizado. A ideia central por detrás do Fluxo de Trabalho de Ramo de Características é que todo o desenvolvimento de características deve ter lugar num ramo dedicado em vez do ramo master. Este encapsulamento facilita o trabalho de múltiplos programadores numa determinada característica sem perturbar a base de código principal. Também significa que o master ramo nunca deve conter código quebrado, o que é uma enorme vantagem para ambientes de integração contínua.

Gitflow Workflow

O Gitflow Workflow foi publicado pela primeira vez num post de blogue altamente considerado de 2010 de Vincent Driessen at nvie. O Gitflow Workflow define um modelo de ramificação rigoroso, concebido em torno do lançamento do projecto. Este fluxo de trabalho não acrescenta quaisquer novos conceitos ou comandos para além do que é necessário para o Fluxo de Trabalho de Ramificação de Funcionalidades. Em vez disso, atribui papéis muito específicos a diferentes ramos e define como e quando estes devem interagir.

Workflow de Forking

O Workflow de Forking é fundamentalmente diferente dos outros fluxos de trabalho discutidos neste tutorial. Em vez de utilizar um único repositório do lado do servidor para actuar como base de código “central”, dá a cada desenvolvedor um repositório do lado do servidor. Isto significa que cada colaborador não tem um, mas dois repositórios Git: um local privado e um público do lado do servidor.

Directrizes

Não há um tamanho único que se ajuste a todo o fluxo de trabalho de Git. Como foi dito anteriormente, é importante desenvolver um fluxo de trabalho de Git que seja um aumento de produtividade para a sua equipa. Para além da cultura de equipa, um fluxo de trabalho deve também complementar a cultura empresarial. Características de Git como sucursais e tags devem complementar o calendário de lançamento do seu negócio. Se a sua equipa estiver a utilizar software de gestão de projectos de rastreio de tarefas, poderá querer utilizar sucursais que correspondam a tarefas em curso. Além disso, algumas directrizes a considerar ao decidir sobre um fluxo de trabalho são:

Ramos de vida curta

Quanto mais tempo um ramo vive separado do ramo de produção, maior é o risco de conflitos de fusão e desafios de implantação. Ramos de vida curta promovem fusões e implantações mais limpas.

Minimizar e simplificar reversões

É importante ter um fluxo de trabalho que ajude a prevenir proactivamente fusões que terão de ser revertidas. Um fluxo de trabalho que teste um ramo antes de permitir a sua fusão no ramo master é um exemplo. No entanto, acidentes acontecem. Dito isto, é benéfico ter um fluxo de trabalho que permita reversões fáceis que não perturbem o fluxo para outros membros da equipa.

Combine um calendário de lançamento

Um fluxo de trabalho deve complementar o ciclo de lançamento de desenvolvimento de software da sua empresa. Se planeia lançar várias vezes por dia, vai querer manter estável o seu master ramo. Se o seu calendário de lançamento for menos frequente, poderá querer considerar a utilização de Git tags para marcar uma filial para uma versão.

Resumo

Neste documento discutimos os fluxos de trabalho de Git. Analisámos em profundidade um Fluxo de Trabalho Centralizado com exemplos práticos. Expandindo o Fluxo de Trabalho Centralizado, discutimos fluxos de trabalho especializados adicionais. Algumas das principais conclusões deste documento são:

• Não há um fluxo de trabalho Git de tamanho único
• Um fluxo de trabalho deve ser simples e aumentar a produtividade da sua equipa
• Os seus requisitos de negócio devem ajudar a moldar o seu fluxo de trabalho Git

Para ler sobre o próximo fluxo de trabalho Git, verifique a nossa repartição exaustiva do Fluxo de Trabalho de Ramo em Destaque.