-
1. Começando
- 1.1 Sobre Controle de Versão
- 1.2 Uma Breve História do Git
- 1.3 O Básico do Git
- 1.4 A Linha de Comando
- 1.5 Instalando o Git
- 1.6 Configuração Inicial do Git
- 1.7 Pedindo Ajuda
- 1.8 Sumário
-
2. Fundamentos de Git
-
3. Branches no Git
-
4. Git no servidor
- 4.1 Os Protocolos
- 4.2 Getting Git on a Server
- 4.3 Gerando Sua Chave Pública SSH
- 4.4 Setting Up the Server
- 4.5 Git Daemon
- 4.6 Smart HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Third Party Hosted Options
- 4.10 Sumário
-
5. Distributed Git
-
6. GitHub
- 6.1 Configurando uma conta
- 6.2 Contribuindo em um projeto
- 6.3 Maintaining a Project
- 6.4 Managing an organization
- 6.5 Scripting GitHub
- 6.6 Summary
-
7. Git Tools
- 7.1 Revision Selection
- 7.2 Interactive Staging
- 7.3 Stashing and Cleaning
- 7.4 Signing Your Work
- 7.5 Searching
- 7.6 Rewriting History
- 7.7 Reset Demystified
- 7.8 Advanced Merging
- 7.9 Rerere
- 7.10 Debugging with Git
- 7.11 Submodules
- 7.12 Bundling
- 7.13 Replace
- 7.14 Credential Storage
- 7.15 Summary
-
8. Customizing Git
- 8.1 Git Configuration
- 8.2 Git Attributes
- 8.3 Git Hooks
- 8.4 An Example Git-Enforced Policy
- 8.5 Summary
-
9. Git and Other Systems
- 9.1 Git as a Client
- 9.2 Migrating to Git
- 9.3 Summary
-
10. Funcionamento Interno do Git
- 10.1 Encanamento e Porcelana
- 10.2 Objetos do Git
- 10.3 Referências do Git
- 10.4 Packfiles
- 10.5 The Refspec
- 10.6 Transfer Protocols
- 10.7 Maintenance and Data Recovery
- 10.8 Variáveis de ambiente
- 10.9 Sumário
-
A1. Appendix A: Git em Outros Ambientes
- A1.1 Graphical Interfaces
- A1.2 Git in Visual Studio
- A1.3 Git in Eclipse
- A1.4 Git in Bash
- A1.5 Git in Zsh
- A1.6 Git in Powershell
- A1.7 Resumo
-
A2. Appendix B: Embedding Git in your Applications
- A2.1 Command-line Git
- A2.2 Libgit2
- A2.3 JGit
-
A3. Appendix C: Git Commands
- A3.1 Setup and Config
- A3.2 Getting and Creating Projects
- A3.3 Basic Snapshotting
- A3.4 Branching and Merging
- A3.5 Sharing and Updating Projects
- A3.6 Inspection and Comparison
- A3.7 Debugging
- A3.8 Patching
- A3.9 Email
- A3.10 External Systems
- A3.11 Administration
- A3.12 Plumbing Commands
5.1 Distributed Git - Fluxos de Trabalho Distribuídos
Now that you have a remote Git repository set up as a point for all the developers to share their code, and you’re familiar with basic Git commands in a local workflow, you’ll look at how to utilize some of the distributed workflows that Git affords you.
In this chapter, you’ll see how to work with Git in a distributed environment as a contributor and an integrator. That is, you’ll learn how to contribute code successfully to a project and make it as easy on you and the project maintainer as possible, and also how to maintain a project successfully with a number of developers contributing.
Fluxos de Trabalho Distribuídos
Em contraste com Sistemas de Controle de Versão Centralizados (CVCSs), a natureza compartilhada do Git permite ser muito mais flexível na maneira que desenvolvedores colaboram em projetos. Em sistemas centralizados, cada desenvolvedor é um nó trabalhando mais ou menos pareado com o ponto central (hub). No Git, entretanto, cada desenvolvedor pode ser tanto um nó quanto um hub; ou seja, cada desenvolvedor pode tanto contribuir para o código de outros repositórios quanto manter um repositório público no qual outros podem basear o trabalho deles e contribuir. Isto permite várias possibilidades no fluxo de trabalho de seu projeto e/ou da sua equipe, então iremos explorar alguns paradigmas comuns que aproveitam esta flexibilidade. Cobriremos os pontos fortes e as possíveis fraquezas de cada design; você poderá escolher apenas um para usar, ou uma combinação de suas características.
Fluxo de Trabalho Centralizado
Em sistemas centralizados, geralmente há um único modelo de colaboração — o fluxo de trabalho centralizado. Um hub central, ou repositório, que pode aceitar código e todos sincronizam seu trabalho com ele. Alguns desenvolvedores são nós — consumidores daquele hub — e sincronizam com aquela localização central.
Isto significa que se dois desenvolvedores clonarem do hub e ambos fizerem alterações, o primeiro desenvolvedor que publicar (push) no servidor pode fazê-lo sem problemas. O segundo desenvolvedor deve mesclar (merge) com o trabalho do primeiro antes de publicar suas mudanças, para não sobrescrever as modificações do primeiro desenvolvedor. Este conceito é tão verdadeiro em Git quanto em Subversion (ou qualquer CVCS), e este modelo funciona perfeitamente bem em Git.
Se você já é confortável com um fluxo de trabalho centralizado na sua companhia ou equipe, pode facilmente continuar usando este fluxo de trabalho com o Git. Simplesmente configure um único repositório, e dê para todos no seu time permissão de publicação (push); Git não permitirá os usuários sobrescreverem-se.
Digamos que John e Jessica começaram a trabalhar ao mesmo tempo. John termina sua modificação e dá um push para o servidor. Então Jessica tenta dar um push das alterações dela, mas o servidor as rejeita. Ela recebe uma mensagem de que está tentando dar um push com modificações conflitantes (non-fast-forward) e que não conseguirá até as resolver e mesclar. Este fluxo de trabalho atrai várias pessoas pois já é um modelo familiar e confortável para muitos.
Isto não é limitado apenas a equipes pequenas. Com o modelo de ramificações do Git, é possível para centenas de desenvolvedores conseguirem trabalhar em um único projeto através de dúzias de ramos (branches) simultaneamente.
Fluxo de Trabalho Coordenado
Como o Git permite ter múltiplos repositórios remotos, é possível ter um fluxo de trabalho onde cada desenvolvedor tem permissão de escrita para o seu próprio repositório, e permissão de leitura para o de todos os outros. Este cenário geralmente inclui um repositório canônico que representa o projeto “oficial”. Para contribuir com este projeto, você cria seu próprio clone público do projeto e dá um push das suas modificações. Então você pode mandar um pedido para os coordenadores do projeto principal para aceitarem (pull) suas mudanças. Os coordenadores podem então adicionar seu repositório como um repositório remoto deles, testar suas mudanças localmente, mesclá-las (merge) nos respectivos branches e publicar (push) no repositório principal. O processo funciona assim (ver Fluxo de trabalho coordenado):
-
Os coordenadores do projeto publicam no repositório público.
-
Um colaborador clona o repositório e faz modificações.
-
O colaborador dá um push para a sua própria cópia pública.
-
Este contribuinte manda aos coordenadores um email pedindo para incluir as modificações.
-
Os coordenadores adicionam o repositório do colaborador como um repositório remoto e o mesclam localmente.
-
Os coordenadores publicam as alterações combinadas no repositório principal.
Este é um fluxo de trabalho bastante comum em ferramentas baseadas em um hub como GitHub ou GitLab, onde é fácil bifurcar (fork) um projeto e publicar suas modificações no seu próprio fork para todos verem. Uma das principais vantagens desta abordagem é que você pode continuar a trabalhar, e os coordenadores do repositório principal podem incluir as suas modificações a qualquer hora. Colaboradores não tem que esperar pelo projeto para incorporar suas mudanças -– cada grupo pode trabalhar na sua própria velocidade.
Fluxo de Trabalho Ditador e Tenentes
Esta é uma variante de um fluxo de trabalho com múltiplos repositórios. É geralmente usada por projetos gigantescos com centenas de colaboradores; um exemplo famoso é o kernel Linux. Vários coordenadores são responsáveis por partes específicas do repositório, eles são chamados tenentes. Todos os tenentes têm um coordenador conhecido como o ditador benevolente. O ditador benevolente publica (push) do diretório deles para um repositório de referência do qual todos os colaboradores precisam buscar (pull). Este processo funciona assim (ver Fluxo de trabalho do ditador benevolente):
-
Desenvolvedores comuns trabalham no seu próprio branch, baseando seu trabalho no
master
. Este branchmaster
é aquele do repositório de referência no qual o ditador publica (push). -
Tenentes mesclam (merge) cada branch dos desenvolvedores ao branch
master
deles. -
O ditador mescla os branches
master
dos tenentes no branchmaster
do ditador. -
Finalmente, o ditador publica aquele branch
master
para o repositório de referência então os desenvolvedores podem se basear nele.
Este tipo de fluxo de trabalho não é comum, mas pode ser útil em projetos muito grandes, ou em ambientes altamente hierárquicos. Ele permite ao líder de projeto (o ditador) delegar muitas tarefas e coletar vários pedaços de código de múltiplas fontes antes de combiná-los.
Padrões para Controlar Branches de Código Fonte
Note
|
Martin Fowler fez um manual "Patterns for Managing Source Code Branches". Este guia cobre todos os fluxos de trabalho comuns, e explica como/quando utilizá-los. Há também uma seção comparando fluxos com muitas ou poucas combinações. |
Resumo do Fluxo de Trabalho
Estes são alguns fluxos de trabalho comumente utilizados graças a sistemas distribuídos como o Git, mas muitas variações podem ser adaptadas ao seu fluxo de trabalho no mundo real. Agora que você é capaz (tomara) de determinar qual combinação de fluxo de trabalho deve funcionar para você, iremos cobrir alguns exemplos mais específicos de como realizar as principais funções que compõem os diferentes fluxos. Na próxima seção, você irá aprender sobre alguns padrões comuns para contribuir com um projeto.