Merge pull request #46 from flaviovisnardifilho/traduzir-5.1

Traduzir distributed-workflows.asc no cap. 5

book/05-distributed-git/sections/distributed-workflows.asc

@@ -1,102 +1,102 @@
-=== Distributed Workflows
+=== Fluxos de Trabalho Distribuídos
 
 (((workflows)))
-In contrast with Centralized Version Control Systems (CVCSs), the distributed nature of Git allows you to be far more flexible in how developers collaborate on projects.
-In centralized systems, every developer is a node working more or less equally with a central hub.
-In Git, however, every developer is potentially both a node and a hub; that is, every developer can both contribute code to other repositories and maintain a public repository on which others can base their work and which they can contribute to.
-This presents a vast range of workflow possibilities for your project and/or your team, so we'll cover a few common paradigms that take advantage of this flexibility.
-We'll go over the strengths and possible weaknesses of each design; you can choose a single one to use, or you can mix and match features from each.
+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.
 
-==== Centralized Workflow
+==== Fluxo de Trabalho Centralizado
 
 (((workflows, centralized)))
-In centralized systems, there is generally a single collaboration model -- the centralized workflow.
-One central hub, or _repository_, can accept code, and everyone synchronizes their work with it.
-A number of developers are nodes -- consumers of that hub -- and synchronize with that centralized location.
+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.
 
-.Centralized workflow
-image::images/centralized_workflow.png[Centralized workflow]
+.Fluxo de trabalho centralizado
+image::images/centralized_workflow.png[Centralized workflow.]
 
-This means that if two developers clone from the hub and both make changes, the first developer to push their changes back up can do so with no problems.
-The second developer must merge in the first one's work before pushing changes up, so as not to overwrite the first developer's changes.
-This concept is as true in Git as it is in Subversion(((Subversion))) (or any CVCS), and this model works perfectly well in Git.
+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(((Subversion))) (ou qualquer CVCS), e este modelo funciona perfeitamente bem em Git.
 
-If you are already comfortable with a centralized workflow in your company or team, you can easily continue using that workflow with Git.
-Simply set up a single repository, and give everyone on your team push access; Git won't let users overwrite each other.
+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.
 
-Say John and Jessica both start working at the same time.
-John finishes his change and pushes it to the server.
-Then Jessica tries to push her changes, but the server rejects them.
-She is told that she's trying to push non-fast-forward changes and that she won't be able to do so until she fetches and merges.
-This workflow is attractive to a lot of people because it's a paradigm that many are familiar and comfortable with.
+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.
 
-This is also not limited to small teams.
-With Git's branching model, it's possible for hundreds of developers to successfully work on a single project through dozens of branches simultaneously.
+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.
 
 [[r_integration_manager]]
-==== Integration-Manager Workflow
+==== Fluxo de Trabalho Coordenado
 
 (((workflows, integration manager)))
-Because Git allows you to have multiple remote repositories, it's possible to have a workflow where each developer has write access to their own public repository and read access to everyone else's.
-This scenario often includes a canonical repository that represents the ``official'' project.
-To contribute to that project, you create your own public clone of the project and push your changes to it.
-Then, you can send a request to the maintainer of the main project to pull in your changes.
-The maintainer can then add your repository as a remote, test your changes locally, merge them into their branch, and push back to their repository.
-The process works as follows (see <<rwfdiag_b>>):
-
-1.  The project maintainer pushes to their public repository.
-2.  A contributor clones that repository and makes changes.
-3.  The contributor pushes to their own public copy.
-4.  The contributor sends the maintainer an email asking them to pull changes.
-5.  The maintainer adds the contributor's repository as a remote and merges locally.
-6.  The maintainer pushes merged changes to the main repository.
+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 <<rwfdiag_b>>):
+
+1. Os coordenadores do projeto publicam no repositório público.
+2. Um colaborador clona o repositório e faz modificações.
+3. O colaborador dá um push para a sua própria cópia pública.
+4. Este contribuinte manda aos coordenadores um email pedindo para incluir as modificações.
+5. Os coordenadores adicionam o repositório do colaborador como um repositório remoto e o mesclam localmente.
+6. Os coordenadores publicam as alterações combinadas no repositório principal.
 
 [[rwfdiag_b]]
-.Integration-manager workflow
+.Fluxo de trabalho coordenado
 image::images/integration-manager.png[Integration-manager workflow]
 
 (((forking)))
-This is a very common workflow with hub-based tools like GitHub or GitLab, where it's easy to fork a project and push your changes into your fork for everyone to see.
-One of the main advantages of this approach is that you can continue to work, and the maintainer of the main repository can pull in your changes at any time.
-Contributors don't have to wait for the project to incorporate their changes -- each party can work at their own pace.
+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.
 
-==== Dictator and Lieutenants Workflow
+==== Fluxo de Trabalho Ditador e Tenentes
 
 (((workflows, dictator and lieutenants)))
-This is a variant of a multiple-repository workflow.
-It's generally used by huge projects with hundreds of collaborators; one famous example is the Linux kernel.
-Various integration managers are in charge of certain parts of the repository; they're called _lieutenants_.
-All the lieutenants have one integration manager known as the benevolent dictator.
-The benevolent dictator pushes from their directory to a reference repository from which all the collaborators need to pull.
-The process works like this (see <<rwfdiag_c>>):
-
-1.  Regular developers work on their topic branch and rebase their work on top of `master`.
-    The `master` branch is that of the reference repository to which the dictator pushes.
-2.  Lieutenants merge the developers' topic branches into their `master` branch.
-3.  The dictator merges the lieutenants' `master` branches into the dictator's `master` branch.
-4.  Finally, the dictator pushes that `master` branch to the reference repository so the other developers can rebase on it.
+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 <<rwfdiag_c>>):
+
+1.  Desenvolvedores comuns trabalham no seu próprio branch, baseando seu trabalho no `master`.
+Este branch `master` é aquele do repositório de referência no qual o ditador publica (_push_).
+2.  Tenentes mesclam (_merge_) cada branch dos desenvolvedores ao branch `master` deles.
+3.  O ditador mescla os branches `master` dos tenentes no branch `master` do ditador.
+4.  Finalmente, o ditador publica aquele branch `master` para o repositório de referência então os desenvolvedores podem se basear nele.
 
 [[rwfdiag_c]]
-.Benevolent dictator workflow
+.Fluxo de trabalho do ditador benevolente
 image::images/benevolent-dictator.png[Benevolent dictator workflow]
 
-This kind of workflow isn't common, but can be useful in very big projects, or in highly hierarchical environments.
-It allows the project leader (the dictator) to delegate much of the work and collect large subsets of code at multiple points before integrating them.
+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.
 
 [[_patterns_for_managing_source_code_branches]]
-==== Patterns for Managing Source Code Branches
+==== Padrões para Controlar Branches de Código Fonte
 
 [NOTE]
 ====
-Martin Fowler has made a guide "Patterns for Managing Source Code Branches".
-This guide covers all the common Git workflows, and explains how/when to use them.
-There's also a section comparing high and low integration frequencies.
+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.
 
-https://martinfowler.com/articles/branching-patterns.html
+https://matinfowler.com/articles/branching-patterns.html
 ====
 
-==== Workflows Summary
+==== Resumo do Fluxo de Trabalho
 
-These are some commonly used workflows that are possible with a distributed system like Git, but you can see that many variations are possible to suit your particular real-world workflow.
-Now that you can (hopefully) determine which workflow combination may work for you, we'll cover some more specific examples of how to accomplish the main roles that make up the different flows.
-In the next section, you'll learn about a few common patterns for contributing to a project.
+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.