Merge pull request #128 from juanpflores/master

Traducción capitulo 5.1

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

@@ -1,7 +1,7 @@
 === Flujos de trabajo distribuidos
 
 (((workflows)))
-A diferencia de Sistemas Centralizados de Control de Versiones (CVCSs, Centralized Version Control Systems),la naturaleza distribuido de Git te permite mucha más flexibilidad en la manera de colaborar en proyectos.
+A diferencia de Sistemas Centralizados de Control de Versiones (CVCSs, Centralized Version Control Systems), la naturaleza distribuido de Git te permite mucha más flexibilidad en la manera de colaborar en proyectos.
 En los sistemas centralizados, cada desarrollador es un nodo de trabajo más o menos en igualdad con un repositorio central. En Git, sin embargo, cada desarrollador es potencialmente un nodo o un repositorio - es decir, cada desarrollador puede contribuir a otros repositorios y mantener un repositorio público en el cual otros pueden basar su trabajo y al cual pueden contribuir.
 
 Esto abre un enorme rango de posibles flujos de trabajo para tu proyecto y/o tu equipo, así que revisaremos algunos de los paradigmas que toman ventajas de esta flexibilidad
@@ -17,9 +17,8 @@ En sistemas centralizados, habitualmente solo hay un modelo de colaboración - e
 image::images/centralized.png[Centralized workflow.]
 
 Esto significa que si dos desarrolladores clonan desde el punto central, y ambos hacen cambios, solo el primer desarrollador en subir sus cambios lo podrá hacer sin problemas.
-El segundo desarrollador debe fusionar el trabajo del primero antes de subir sus cambios, para no sobreescribir los cambios del primero.
-Este concepto es válido tanto en Git como en Subversion 
-This concept is as true in Git as it is in Subversion(((Subversion))) (or any CVCS), and this model works perfectly well in Git.
+El segundo desarrollador debe fusionar el trabajo del primero antes de subir sus cambios, para no sobrescribir los cambios del primero.
+Este concepto es válido tanto en Git como en Subversion.
 
 Si ya está cómodo con un flujo de trabajo centralizado en su empresa o en su equipo, puede seguir utilizando fácilmente ese flujo de trabajo con Git.
 Simplemente configure un único repositorio, y dé a cada uno en su equipo acceso de empuje; Git no permitirá que los usuarios se sobrescriban entre sí.
@@ -32,57 +31,56 @@ Este flujo de trabajo es atractivo para mucha gente porque es un paradigma que m
 Esto tampoco se limita a los equipos pequeños. Con el modelo de ramificación de Git, es posible que cientos de desarrolladores trabajen con éxito en un único proyecto a través de docenas de ramas simultáneamente.
 
 [[r_integration_manager]]
-==== Integration-Manager Workflow
+==== Flujo de Trabajo Administrador-Integración
 
 (((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 e-mail asking them to pull changes.
-5.  The maintainer adds the contributor's repo as a remote and merges locally.
-6.  The maintainer pushes merged changes to the main repository.
+
+Debido a que Git permite tener múltiples repositorios remotos, es posible tener un flujo de trabajo donde cada desarrollador tenga acceso de escritura a su propio repositorio público y acceso de lectura a todos los demás.
+Este escenario a menudo incluye un repositorio canónico que representa el proyecto "oficial".
+Para contribuir a ese proyecto, creas tu propio clon público del proyecto y haces pull con tus cambios.
+Luego, puede enviar una solicitud al administrador del proyecto principal para que agregue los cambios.
+Entonces, el administrador agrega el repositorio como remoto, prueba los cambios localmente, combinarlos en su rama y enviarlos al repositorio.
+El proceso funciona de la siguiente manera. (ver <<rwfdiag_b>>):
+
+1.  El administrador del proyecto hace un push al repositorio público.
+2.  El contribuidor clona ese repositorio y realiza los cambios.
+3.  El contribuidor realiza un push con su copia pública del proyecto.
+4.  El contribuidor envía un correo electrónico al administrador pidiendo que haga pull de los cambios.
+5.  El administrador agrega el repositorio del contribuidor como remoto y fusiona ambos localmente.
+6.  El administrador realiza un push con la fusión del código al repositorio principal.
 
 [[rwfdiag_b]]
-.Integration-manager workflow.
-image::images/integration-manager.png[Integration-manager workflow.]
+.Flujo de Trabajo Administrador-Integración.
+image::images/integration-manager.png[Flujo de Trabajo Administrador-Integración.]
 
 (((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.
 
-==== Dictator and Lieutenants Workflow
+Este es un flujo de trabajo muy común con herramientas basadas en hubs como GitHub o GitLab, donde es fácil hacer un fork de un proyecto e introducir los cambios en este fork para que todos puedan verlos.
+Una de las principales ventajas de este enfoque es que el contribuidor puede continuar realizando cambios y el administrador principal del repositorio puede incorporar los cambios en cualquier momento.
+Los contribuidores no tienen que esperar a que el proyecto incorpore sus cambios; cada parte puede trabajar a su propio ritmo.
+
+==== Flujo de Trabajo Dictador-Tenientes
 
 (((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's repository serves as the 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 dictator.
-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.  The dictator pushes their `master` to the reference repository so the other developers can rebase on it.
+Esta es una variante de un flujo de trabajo de múltiples repositorios.
+Generalmente es utilizado por grandes proyectos con cientos de colaboradores; Un ejemplo famoso es el kernel de Linux.
+Varios administradores de integración están a cargo de ciertas partes del repositorio; Se les llaman tenientes.
+Todos los tenientes tienen un gerente de integración conocido como el dictador benévolo.
+El repositorio del dictador benevolente sirve como el repositorio de referencia del cual todos los colaboradores necesitan realizar pull.
+El proceso funciona así. (ver <<rwfdiag_c>>):
+
+1.  Los desarrolladores trabajan en su propia rama especifica y fusionan su código en la rama `master`, la cual, es una copia de la rama del dictador.
+2.  Los tenientes fusionan el código de las ramas `master` de los desarrolladores en sus ramas `master` de tenientes.
+3.  El dictador fusiona la rama `master` de los tenientes a su rama `master` de dictador.
+4.  El dictador hace push del contenido de su rama `master` al repositorio para que otros fusionen los cambios a sus ramas.
 
 [[rwfdiag_c]]
-.Benevolent dictator workflow.
-image::images/benevolent-dictator.png[Benevolent dictator workflow.]
+.Flujo de Trabajo Dictador Benevolente.
+image::images/benevolent-dictator.png[Flujo de Trabajo Dictador Benevolente.]
 
-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 flujo de trabajo no es común, pero puede ser útil en proyectos muy grandes o en entornos altamente jerárquicos.
+Permite al líder del proyecto (el dictador) delegar gran parte del trabajo y recopilar grandes subconjuntos de código en múltiples puntos antes de integrarlos.
 
-==== Workflows Summary
+==== Resumen de Flujos de Trabajo
 
-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.
+Estos son algunos de los flujos de trabajo de uso común que son posibles con un sistema distribuido como Git, pero se puede observar que hay muchas posibles variaciones que buscan adaptarse a tu flujo de trabajo particular. Ahora puedes (con suerte) determinar qué combinación de flujo de trabajo puede funcionar mejor para ti, cubriremos algunos ejemplos más específicos sobre cómo cumplir los roles principales que conforman los diferentes flujos. En la siguiente sección, aprenderá sobre algunos patrones comunes para contribuir a un proyecto.