Merge pull request #131 from ChristAlbert/master

Pequeño cambio de vocabulario

Author: andres-mancera

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

@@ -50,7 +50,7 @@ A continuación, intente hacer que cada commit un conjunto de cambios lógicamen
 Si puede, trate de hacer que sus cambios sean digeribles: no codifique durante un fin de semana entero en cinco asuntos diferentes y luego envíelos todos como un compromiso masivo el lunes.
 Incluso si no confirmas durante el fin de semana, utilice el área de etapas el lunes para dividir su trabajo en al menos una confirmación por cuestión, con un mensaje útil por confirmación.
 Si algunos de los cambios modifican el mismo archivo, intente utilizar `git add --patch` para representar parcialmente los archivos (se detalla en << _ interactive_staging >>).
-La instantánea del proyecto en la punta de la sucursal es idéntica ya sea que realice una confirmación o cinco, siempre que todos los cambios se agreguen en algún momento, así que trate de facilitar las cosas a sus compañeros desarrolladores cuando tengan que revisar sus cambios.
+La instantánea del proyecto en la punta de la rama es idéntica ya sea que realice una confirmación o cinco, siempre que todos los cambios se agreguen en algún momento, así que trate de facilitar las cosas a sus compañeros desarrolladores cuando tengan que revisar sus cambios.
 Este enfoque también hace que sea más fácil retirar o revertir uno de los conjuntos de cambios si lo necesita más adelante.
 << _ rewriting_history >> describe una serie de útiles trucos de Git para reescribir el historial y organizar de forma interactiva los archivos: use estas herramientas para crear un historial limpio y comprensible antes de enviar el trabajo a otra persona.
 
@@ -315,11 +315,11 @@ Aprenderá cómo trabajar en un entorno en el que los grupos pequeños colaboran
 
 Digamos que John y Jessica están trabajando juntos en una característica, mientras que Jessica y Josie están trabajando en una segunda.
 En este caso, la compañía está utilizando un tipo de flujo de trabajo de integración-gerente donde el trabajo de los grupos individuales está integrado solo por ciertos ingenieros, y la rama `maestra` del repositorio principal solo puede ser actualizada por esos ingenieros.
-En este escenario, todo el trabajo se realiza en sucursales basadas en equipos y luego los integradores lo agrupan.
+En este escenario, todo el trabajo se realiza en ramas basadas en equipos y luego los integradores lo agrupan.
 
 Sigamos el flujo de trabajo de Jessica mientras trabaja en sus dos funciones, colaborando en paralelo con dos desarrolladores diferentes en este entorno.
 Suponiendo que ya haya clonado su repositorio, ella decide trabajar primero en `featureA`.
-Ella crea una nueva sucursal para la característica y hace algo de trabajo allí:
+Ella crea una nueva rama para la característica y hace algo de trabajo allí:
 
 [source,console]
 -----
@@ -333,7 +333,7 @@ $ git commit -am 'add limit to log function'
 -----
 
 En este punto, ella necesita compartir su trabajo con John, por lo que empuja a su rama `featureA` a comprometerse con el servidor.
-Jessica no tiene acceso de inserción a la rama `maestra`, solo los integradores lo hacen, por lo que debe enviar a otra sucursal para colaborar con John:
+Jessica no tiene acceso de inserción a la rama `maestra`, solo los integradores lo hacen, por lo que debe enviar a otra rama para colaborar con John:
 
 [source,console]
 -----
@@ -343,7 +343,7 @@ To jessica@githost:simplegit.git
  * [new branch]      featureA -> featureA
 -----
 
-Jessica le envía un correo electrónico a John para decirle que ha enviado algo de trabajo a una sucursal llamada `featureA` y ahora puede verlo.
+Jessica le envía un correo electrónico a John para decirle que ha enviado algo de trabajo a una rama llamada `featureA` y ahora puede verlo.
 Mientras espera los comentarios de John, Jessica decide comenzar a trabajar en `featureB` con Josie.
 Para comenzar, inicia una nueva rama de características, basándose en la rama `master` del servidor:
 
@@ -473,7 +473,7 @@ Después de que los integradores fusionen estas ramas en la línea principal, un
 image::images/managed-team-3.png[Jessica's history after merging both her topic branches.]
 
 Muchos grupos cambian a Git debido a esta capacidad de tener varios equipos trabajando en paralelo, fusionando las diferentes líneas de trabajo al final del proceso.
-La capacidad de los subgrupos más pequeños de un equipo para colaborar a través de sucursales remotas sin necesariamente tener que involucrar o impedir a todo el equipo es un gran beneficio de Git.
+La capacidad de los subgrupos más pequeños de un equipo para colaborar a través de ramas remotas sin necesariamente tener que involucrar o impedir a todo el equipo es un gran beneficio de Git.
 La secuencia del flujo de trabajo que vio aquí es algo como esto:
 
 .Basic sequence of this managed-team workflow.
@@ -508,7 +508,7 @@ $ git commit
 Puede usar `rebase -i` para reducir su trabajo a una única confirmación, o reorganizar el trabajo en las confirmaciones para que el desarrollador pueda revisar el parche más fácilmente. Consulte << _ rewriting_history >> para obtener más información sobre el rebase interactivo. 
 ====
 
-Cuando finalice el trabajo de sucursal y esté listo para contribuir con los mantenedores, vaya a la página original del proyecto y haga clic en el botón `` Tenedor '', creando su propio tenedor escribible del proyecto.
+Cuando finalice el trabajo de rama y esté listo para contribuir con los mantenedores, vaya a la página original del proyecto y haga clic en el botón `` Tenedor '', creando su propio tenedor escribible del proyecto.
 Luego debe agregar este nuevo URL de repositorio como segundo control remoto, en este caso llamado `myfork`:
 
 [source,console]
@@ -573,7 +573,7 @@ Ahora, cada uno de sus temas está contenido dentro de un silo, similar a una fi
 .Initial commit history with `featureB` work.
 image::images/public-small-1.png[Initial commit history with `featureB` work.]
 
-Digamos que el mantenedor del proyecto ha sacado otros parches y ha probado su primera sucursal, pero ya no se fusiona de manera limpia.
+Digamos que el mantenedor del proyecto ha sacado otros parches y ha probado su primera rama, pero ya no se fusiona de manera limpia.
 En este caso, puede tratar de volver a establecer la base de esa rama sobre 'origin / master', resolver los conflictos del mantenedor y luego volver a enviar los cambios:
 
 [source,console]
@@ -592,9 +592,9 @@ image::images/public-small-2.png[Commit history after `featureA` work.]
 Debido a que rebasaste la rama, debes especificar el `-f` en tu comando push para poder reemplazar la rama` featureA` en el servidor con una confirmación que no sea un descendiente de ella.
 Una alternativa sería llevar este nuevo trabajo a una rama diferente en el servidor (tal vez llamada `featureAv2`).
 
-Veamos un escenario más posible: el mantenedor ha observado el trabajo en su segunda sucursal y le gusta el concepto, pero le gustaría que cambie un detalle de implementación.
+Veamos un escenario más posible: el mantenedor ha observado el trabajo en su segunda rama y le gusta el concepto, pero le gustaría que cambie un detalle de implementación.
 También aprovechará esta oportunidad para mover el trabajo basado en la rama `maestra 'actual del proyecto.
-Usted inicia una nueva sucursal basada en la rama actual de 'origen / maestro', aplasta los cambios `featureB` allí, resuelve cualquier conflicto, hace que la implementación cambie, y luego lo empuja hacia arriba como una nueva sucursal:
+Usted inicia una nueva rama basada en la rama actual de 'origen / maestro', aplasta los cambios `featureB` allí, resuelve cualquier conflicto, hace que la implementación cambie, y luego lo empuja hacia arriba como una nueva rama:
 
 (((git commands, merge, squash)))
 [source,console]

book/09-git-and-other-scms/sections/client-p4.asc

@@ -653,7 +653,7 @@ Si ahora `git checkout -b dev p4/project/dev` y realizamos algunas commits, git-
 Desafortunadamente, git-p4 no puede mezclar clones superficiales y ramas múltiples; si tienes un gran proyecto y quieres trabajar en más de una, tendrás que 'git p4 clone' una vez por cada rama a la que quieras enviar.
 
 Para crear o integrar ramas, deberá usar un cliente Perforce.
-Git-p4 solo puede sincronizar y enviar a las sucursales existentes, y solo puede hacerlo un conjunto de cambios lineal a la vez.
+Git-p4 solo puede sincronizar y enviar a las ramas existentes, y solo puede hacerlo un conjunto de cambios lineal a la vez.
 Si combina dos ramas en Git e intenta enviar el nuevo conjunto de cambios, todo lo que se registrará será un conjunto de cambios de archivos; los metadatos sobre qué ramas están involucradas en la integración se perderán.
 
 ===== Resumen de Git y Perforce

book/09-git-and-other-scms/sections/client-svn.asc

@@ -159,7 +159,7 @@ c3dcbe8488c6240392e8a5d7553bbffcb0f94ef0 refs/remotes/origin/master
 6dcb09b5b57875f334f61aebed695e2e4193db5e refs/tags/v1.0.0
 ----
 
-Git busca las etiquetas directamente en `refs / tags`, en lugar de tratarlas en sucursales remotas.
+Git busca las etiquetas directamente en `refs / tags`, en lugar de tratarlas en ramas remotas.
 
 ===== Comprometerse con la subversión
 
@@ -362,7 +362,7 @@ Es importante tener en cuenta que no te echa un vistazo en esa rama; si confirma
 
 Git averigua a qué rama se dirigen tus dcommits buscando la punta de cualquiera de tus ramas de Subversion en tu historial: debes tener solo una, y debería ser la última con un `git-svn-id` en tu rama actual del historial historia.
 
-Si desea trabajar en más de una sucursal al mismo tiempo, puede configurar las sucursales locales para `compromentar` a las sucursales de Subversion específicas, comenzándolas en la confirmación de Subversion importada para esa sucursal.
+Si desea trabajar en más de una rama al mismo tiempo, puede configurar las ramas locales para `compromentar` a las ramas de Subversion específicas, comenzándolas en la confirmación de Subversion importada para esa rama.
 Si desea que una rama `opera ' pueda trabajar por separado, puede ejecutar
 
 [source,console]

book/09-git-and-other-scms/sections/client-tfs.asc

@@ -28,7 +28,7 @@ Esto significa que necesitará acceso a esos ensamblados, lo que significa que n
 
 Git-tf (cuyo domicilio se encuentra en https://gittf.codeplex.com []) es un proyecto de Java y, como tal, se ejecuta en cualquier computadora con un entorno de tiempo de ejecución de Java.
 Interactúa con los repositorios de Git a través de JGit (una implementación JVM de Git), lo que significa que prácticamente no tiene limitaciones en términos de funciones de Git.
-Sin embargo, su soporte para TFVC es limitado en comparación con git-tfs; por ejemplo, no admite sucursales.
+Sin embargo, su soporte para TFVC es limitado en comparación con git-tfs; por ejemplo, no admite ramas.
 
 Entonces, cada herramienta tiene ventajas y desventajas, y hay muchas situaciones que favorecen a una sobre la otra.
 Cubriremos el uso básico de ambos en este libro.

book/09-git-and-other-scms/sections/import-svn.asc

@@ -69,7 +69,7 @@ $ rm -Rf .git/refs/remotes/origin/tags
 
 Esto toma las referencias que eran ramas remotas que comenzaron con controles remotos / origen / etiquetas / y las convierte en etiquetas reales (ligeras).
 
-A continuación, mueva el resto de las referencias en refs / remotes para que sean sucursales locales:
+A continuación, mueva el resto de las referencias en refs / remotes para que sean ramas locales:
 
 [source,console]
 ----