Traducción signing.asc y status.json

book/01-introduction/1-introduction.asc

@@ -1,7 +1,7 @@
 [[_getting_started]]
 == Inicio - Sobre el Control de Versiones
 
-Este capítulo habla de cómo comenzar a utilizar Git.  Empezaremos describiendo algunos conceptos básicos sobre las herramientas de control de versiones;  después, trataremos sobre cómo hacer que Git funcione en tu sistema; finalmente, exploraremos cómo configurarlo para empezar a trabajar con él.  Al final de este capítulo deberás entender las razones por las cuales Git existe y conviene que lo uses, y deberás tener todo preparado para comenzar.
+Este capítulo se va a hablar de cómo comenzar a utilizar Git.  Empezaremos describiendo algunos conceptos básicos sobre las herramientas de control de versiones;  después, trataremos de explicar cómo hacer que Git funcione en tu sistema; finalmente, exploraremos cómo configurarlo para empezar a trabajar con él.  Al final de este capítulo deberás entender las razones por las cuales Git existe y conviene que lo uses, y deberás tener todo preparado para comenzar.
 
 include::sections/about-version-control.asc[]
 
@@ -19,4 +19,4 @@ include::sections/help.asc[]
 
 === Resumen
 
-Para este momento debes tener una comprensión básica de lo que es Git, y de cómo se diferencia de cualquier otro sistema de control de versiones centralizado que pudieras haber utilizado previamente.  De igual manera, Git debe estar funcionando en tu sistema y configurado con tu identidad personal.  Es hora de aprender los fundamentos de Git.
+En este momento debes tener una comprensión básica de lo que es Git, y en que se diferencia de cualquier otro sistema de control de versiones centralizado que pudieras haber utilizado previamente.  De igual manera, Git debe estar funcionando en tu sistema y configurado con tu identidad personal.  Es hora de aprender los fundamentos de Git.

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

@@ -21,15 +21,15 @@ El segundo desarrollador debe fusionar el trabajo del primero antes de subir sus
 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.
 
-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.
-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.
-
-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.
+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í.
+Digamos que John y Jessica empiezan a trabajar al mismo tiempo.
+John termina su cambio y lo empuja al servidor.
+Entonces Jessica intenta empujar sus cambios, pero el servidor los rechaza.
+Le dicen que está tratando de empujar cambios no rápidos y que no podrá hacerlo hasta que busque y se fusione.
+Este flujo de trabajo es atractivo para mucha gente porque es un paradigma que muchos están familiarizados y cómodos.
+
+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.
 
 [[_integration_manager]]
 ==== Integration-Manager Workflow

book/07-git-tools/1-git-tools.asc

@@ -1,10 +1,10 @@
 [[_git_tools]]
-== Git Tools
+== Herramientas de Git
 
-By now, you’ve learned most of the day-to-day commands and workflows that you need to manage or maintain a Git repository for your source code control.
-You’ve accomplished the basic tasks of tracking and committing files, and you’ve harnessed the power of the staging area and lightweight topic branching and merging.
+Por ahora, ha aprendido la mayoría de los comandos y flujos de trabajo del día a día que necesita para administrar o mantener un repositorio de Git para su control de código fuente.
+Has logrado las tareas básicas de rastrear y comprometer archivos y has aprovechado el poder de la zona de puesta en escena y el tema ligero de ramificación y fusión.
 
-Now you’ll explore a number of very powerful things that Git can do that you may not necessarily use on a day-to-day basis but that you may need at some point.
+Ahora explorará una serie de cosas muy poderosas que Git puede hacer que no necesariamente puede utilizar en el día a día, pero que puede que necesite en algún momento.
 
 include::sections/revision-selection.asc[]
 
@@ -34,9 +34,9 @@ include::sections/replace.asc[]
 
 include::sections/credentials.asc[]
 
-=== Summary
+=== Resumen
 
-You’ve seen a number of advanced tools that allow you to manipulate your commits and staging area more precisely.
-When you notice issues, you should be able to easily figure out what commit introduced them, when, and by whom.
-If you want to use subprojects in your project, you’ve learned how to accommodate those needs.
-At this point, you should be able to do most of the things in Git that you’ll need on the command line day to day and feel comfortable doing so.
+Ha visto una serie de herramientas avanzadas que le permiten manipular sus compromisos y el área de puesta en escena con mayor precisión.
+Cuando note problemas, debería ser capaz de averiguar fácilmente qué commit los introdujo, cuándo y por quién.
+Si desea utilizar subproyectos en su proyecto, ha aprendido a adaptarse a esas necesidades.
+En este punto, usted debe ser capaz de hacer la mayoría de las cosas en Git que usted necesita en la línea de comandos día a día y se sienten cómodos haciéndolo.

book/07-git-tools/sections/replace.asc

@@ -1,15 +1,15 @@
 [[_replace]]
 === Replace
 
-Git's objects are unchangeable, but it does provide an interesting way to pretend to replace objects in it's database with other objects.
+Los objetos de Git son inmutables, pero proporciona una manera interesante de pretender reemplazar objetos en su base de datos con otros objetos.
 
-The `replace` command lets you specify an object in Git and say "every time you see this, pretend it's this other thing". This is most commonly useful for replacing one commit in your history with another one.
+El comando `replace` le permite especificar un objeto en Git y decir" cada vez que vea esto, fingir que es esta otra cosa ". Esto es más útil para reemplazar un commit en tu historia con otro.
 
-For example, let's say you have a huge code history and want to split your repository into one short history for new developers and one much longer and larger history for people interested in data mining.  You can graft one history onto the other by `replace`ing the earliest commit in the new line with the latest commit on the older one.  This is nice because it means that you don't actually have to rewrite every commit in the new history, as you would normally have to do to join them together (because the parentage effects the SHA-1s).
+Por ejemplo, supongamos que tiene un gran historial de códigos y desea dividir su repositorio en un breve historial para nuevos desarrolladores y una historia mucho más larga para las personas interesadas en la minería de datos. Puede injertar una historia en la otra mediante `replace`ing el commit más antiguo en la nueva línea con el último commit en el anterior. Esto es bueno porque significa que en realidad no tienes que reescribir cada commit en la nueva historia, como normalmente tendrías que hacer para unirlos juntos (porque el parentesco efectúa los SHA-1s).
 
-Let's try this out.  Let's take an existing repository, split it into two repositories, one recent and one historical, and then we'll see how we can recombine them without modifying the recent repositories SHA-1 values via `replace`.
+Vamos a probar esto. Tomemos un repositorio existente, lo dividimos en dos repositorios, uno reciente y otro histórico, y luego veremos cómo podemos recombinarlos sin modificar los repositorios recientes SHA-1 a través de `replace`.
 
-We'll use a simple repository with five simple commits:
+Usaremos un repositorio sencillo con cinco compromisos simples:
 
 [source,console]
 ----
@@ -21,11 +21,11 @@ c6e1e95 fourth commit
 c1822cf first commit
 ----
 
-We want to break this up into two lines of history.  One line goes from commit one to commit four - that will be the historical one.  The second line will just be commits four and five - that will be the recent history.
+zQueremos dividir esto en dos líneas de la historia. Una línea pasa de comprometer uno a cometer cuatro - que será el histórico. La segunda línea sólo se compromete cuatro y cinco - que será la historia reciente.
 
 image::images/replace1.png[]
 
-Well, creating the historical history is easy, we can just put a branch in the history and then push that branch to the master branch of a new remote repository.
+Bueno, la creación de la historia histórica es fácil, sólo podemos poner una rama en la historia y luego empujar esa rama a la rama principal de un nuevo repositorio remoto.
 
 [source,console]
 ----
@@ -40,7 +40,7 @@ c1822cf first commit
 
 image::images/replace2.png[]
 
-Now we can push the new `history` branch to the `master` branch of our new repository:
+Ahora podemos hacer push a la nueva rama `history` a la rama` master` de nuestro nuevo repositorio:
 
 [source,console]
 ----
@@ -56,7 +56,7 @@ To git@github.com:schacon/project-history.git
  * [new branch]      history -> master
 ----
 
-OK, so our history is published.  Now the harder part is truncating our recent history down so it's smaller. We need an overlap so we can replace a commit in one with an equivalent commit in the other, so we're going to truncate this to just commits four and five (so commit four overlaps).
+OK, así que nuestra historia se publica. Ahora la parte más difícil es truncar nuestra historia reciente por lo que es más pequeño. Necesitamos una superposición para que podamos reemplazar un commit en uno con un commit equivalente en el otro, por lo que vamos a truncar esto a sólo comete cuatro y cinco (así cometer cuatro superposiciones).
 
 [source,console]
 ----
@@ -68,9 +68,9 @@ c6e1e95 (history) fourth commit
 c1822cf first commit
 ----
 
-It's useful in this case to create a base commit that has instructions on how to expand the history, so other developers know what to do if they hit the first commit in the truncated history and need more. So, what we're going to do is create an initial commit object as our base point with instructions, then rebase the remaining commits (four and five) on top of it.
+En este caso, es útil crear un commit de base que tenga instrucciones sobre cómo expandir el historial, por lo que otros desarrolladores saben qué hacer si acceden al primer commit en el historial truncado y necesitan más. Por lo tanto, lo que vamos a hacer es crear un objeto de confirmación inicial como nuestro punto base con instrucciones, luego rebase los compromisos restantes (cuatro y cinco) encima de él.
 
-To do that, we need to choose a point to split at, which for us is the third commit, which is `9c68fdc` in SHA-speak. So, our base commit will be based off of that tree. We can create our base commit using the `commit-tree` command, which just takes a tree and will give us a brand new, parentless commit object SHA-1 back.
+Para ello, debemos elegir un punto para dividir en, que para nosotros es el tercer commit, que es `9c68fdc` en SHA-speak. Por lo tanto, nuestra comisión base se basará en ese árbol. Podemos crear nuestro commit base con el comando `commit-tree`, que solo toma un árbol y nos dará un nuevo objeto de commit sin padres SHA-1.
 
 [source,console]
 ----
@@ -80,12 +80,12 @@ $ echo 'get history from blah blah blah' | git commit-tree 9c68fdc^{tree}
 
 [NOTE]
 =====
-The `commit-tree` command is one of a set of commands that are commonly referred to as 'plumbing' commands. These are commands that are not generally meant to be used directly, but instead are used by **other** Git commands to do smaller jobs. On occasions when we're doing weirder things like this, they allow us to do really low-level things but are not meant for daily use. You can read more about plumbing commands in <<_plumbing_porcelain>>
+El comando `commit-tree` es uno de un conjunto de comandos que comúnmente se denominan comandos 'plumbing'. Estos son comandos que no suelen ser utilizados directamente, sino que son utilizados por ** ** ** otros comandos Git para hacer trabajos más pequeños. En ocasiones, cuando estamos haciendo cosas más extrañas como estas, nos permiten hacer cosas de nivel muy bajo, pero no son para uso diario. Puede leer más acerca de los comandos de plomería en << _ plumbing_porcelain >>
 =====
 
 image::images/replace3.png[]
 
-OK, so now that we have a base commit, we can rebase the rest of our history on top of that with `git rebase --onto`.  The `--onto` argument will be the SHA-1 we just got back from `commit-tree` and the rebase point will be the third commit (the parent of the first commit we want to keep, `9c68fdc`):
+OK, así que ahora que tenemos un commit de base, podemos rebase el resto de nuestra historia encima de eso con 'rebase de git --onto`. El argumento `--onto` será el SHA-1 que acabamos de regresar de` commit-tree` y el punto de rebase será el tercer commit (el padre del primer commit que queremos mantener, `9c68fdc`):
 
 [source,console]
 ----
@@ -97,10 +97,10 @@ Applying: fifth commit
 
 image::images/replace4.png[]
 
-OK, so now we've re-written our recent history on top of a throw away base commit that now has instructions in it on how to reconstitute the entire history if we wanted to. We can push that new history to a new project and now when people clone that repository, they will only see the most recent two commits and then a base commit with instructions.
+Así que ahora hemos re-escrito nuestra historia reciente en la parte superior de un tiro de base de comisión que ahora tiene instrucciones sobre cómo reconstruir toda la historia si queríamos. Podemos empujar esa nueva historia a un nuevo proyecto y ahora, cuando las personas clonen ese repositorio, solo verán los dos compromisos más recientes y luego un commit de base con instrucciones.
 
-Let's now switch roles to someone cloning the project for the first time who wants the entire history.
-To get the history data after cloning this truncated repository, one would have to add a second remote for the historical repository and fetch:
+Cambiemos de roles a alguien que clonara el proyecto por primera vez y que quiere toda la historia.
+Para obtener los datos del historial después de clonar este repositorio truncado, habría que añadir un segundo mando a distancia para el repositorio histórico y buscar:
 
 [source,console]
 ----
@@ -118,7 +118,7 @@ From https://github.com/schacon/project-history
  * [new branch]      master     -> project-history/master
 ----
 
-Now the collaborator would have their recent commits in the `master` branch and the historical commits in the `project-history/master` branch.
+Ahora el colaborador tendría sus compromisos recientes en la rama `master` y los compromisos históricos en la rama `project-history/master`.
 
 [source,console]
 ----
@@ -134,14 +134,14 @@ c6e1e95 fourth commit
 c1822cf first commit
 ----
 
-To combine them, you can simply call `git replace` with the commit you want to replace and then the commit you want to replace it with.  So we want to replace the "fourth" commit in the master branch with the "fourth" commit in the `project-history/master` branch:
+Para combinarlos, simplemente puede llamar a `git replace` con el commit que desea reemplazar y luego el commit con el que desea reemplazarlo. Así que queremos reemplazar el "cuarto" commit en la rama maestra con el "cuarto" commit en la rama `project-history/master`:
 
 [source,console]
 ----
 $ git replace 81a708d c6e1e95
 ----
 
-Now, if you look at the history of the `master` branch, it appears to look like this:
+Ahora bien, si nos fijamos en la historia de la rama `master`, parece que se ve así:
 
 [source,console]
 ----
@@ -153,11 +153,11 @@ e146b5f fifth commit
 c1822cf first commit
 ----
 
-Cool, right?  Without having to change all the SHA-1s upstream, we were able to replace one commit in our history with an entirely different commit and all the normal tools (`bisect`, `blame`, etc) will work how we would expect them to.
+Genial, ¿verdad? Sin tener que cambiar todos los SHA-1s upstream, pudimos reemplazar un commit en nuestra historia con un commit totalmente diferente y todas las herramientas normales (`bisect`,` blame`, etc.) funcionarán como esperamos .
 
 image::images/replace5.png[]
 
-Interestingly, it still shows `81a708d` as the SHA-1, even though it's actually using the `c6e1e95` commit data that we replaced it with.  Even if you run a command like `cat-file`, it will show you the replaced data:
+Curiosamente, todavía muestra `81a708d` como el SHA-1, a pesar de que en realidad está utilizando los datos de confirmación` c6e1e95` con los que lo reemplazamos. Incluso si ejecuta un comando como `cat-file`, le mostrará los datos reemplazados:
 
 [source,console]
 ----
@@ -170,9 +170,9 @@ committer Scott Chacon <schacon@gmail.com> 1268712581 -0700
 fourth commit
 ----
 
-Remember that the actual parent of `81a708d` was our placeholder commit (`622e88e`), not `9c68fdce` as it states here.
+Recuerde que el padre real de `81a708d` fue nuestro placeholder commit (`622e88e`), no `9c68fdce`, como se indica aquí.
 
-Another interesting thing is that this data is kept in our references:
+Otra cosa interesante es que estos datos se guardan en nuestras referencias:
 
 [source,console]
 ----
@@ -184,4 +184,4 @@ e146b5f14e79d4935160c0e83fb9ebe526b8da0d commit	refs/remotes/origin/master
 c6e1e95051d41771a649f3145423f8809d1a74d4 commit	refs/replace/81a708dd0e167a3f691541c7a6463343bc457040
 ----
 
-This means that it's easy to share our replacement with others, because we can push this to our server and other people can easily download it.  This is not that helpful in the history grafting scenario we've gone over here (since everyone would be downloading both histories anyhow, so why separate them?) but it can be useful in other circumstances.
+Esto significa que es fácil compartir nuestro reemplazo con otros, porque podemos empujar esto a nuestro servidor y otras personas pueden descargarlo fácilmente. Esto no es tan útil en el escenario de injerto de historia que hemos pasado aquí (ya que todo el mundo estaría descargando ambas historias de todos modos, ¿por qué separarlas?), Pero puede ser útil en otras circunstancias.