Realizo varias correcciones ortográficas (y algunas gramaticales y de…

… contexto) en todos los archivos (menos en drawbacks.txt y spanish.txt), cambio "foto" por "instantánea" (me parece que es una mejor traducción para "snapshot") y actualizo un párrafo de clone.txt a partir de la version en ingles.

También traduzco el ejemplo de la sección "Haciendo Historia" de history.txt y los ejemplos que aparecen a lo largo de multiplayer.txt.

es/basic.txt

@@ -9,7 +9,7 @@ Estás a punto de intentar algo drástico? Antes de hacerlo, toma una instantán
 
  $ git init
  $ git add .
- $ git commit -m "My first backup"
+ $ git commit -m "Mi primer respaldo"
 
 Ahora, si tu edición se vuelve irrecuperable, ejecuta:
 
@@ -61,7 +61,7 @@ Para retomar la analogía de los videojuegos:
 
 - *`git reset \--hard`*: carga un juego viejo y borra todos los que son mas nuevos que el que acabas de cargar.
 
-- *`git checkout`*: carga un juego viejo, pero si continúas jugando, el estado del juego se desviará de los juegos que salvaste la primera vez. Cualquierpartido nuevo que guardes, terminará en una branch separada, representando la realidad alternativa a la que entraste. <<branch,Luego nos encargaremos de esto>>
+- *`git checkout`*: carga un juego viejo, pero si continúas jugando, el estado del juego se desviará de los juegos que salvaste la primera vez. Cualquier partida nueva que guardes, terminará en una branch separada, representando la realidad alternativa a la que entraste. <<branch,Luego nos encargaremos de esto>>
 
 Puedes elegir el restaurar solo archivos o directorios en particular, al agregarlos al final del comando:
 
@@ -135,7 +135,7 @@ y tus usuarios puede actualizar su versión yendo al directorio que tiene tu scr
 
 Tus usuarios nunca terminarán usando una versión de tu script que no quieres que vean. Obviamente este truco funciona para lo que sea, no solo scripts.
 
-=== Que es lo que hice? ===
+=== ¿Que es lo que hice? ===
 
 Averigua que cambios hiciste desde el último commit con:
 
@@ -149,7 +149,7 @@ O entre una versión en particular y 2 versiones hacia atrás:
 
  $ git diff SHA1_HASH "master~2"
 
-En cado caso la salida es un patch (parche) que puede ser aplicado con *git apply*
+En cada caso la salida es un patch (parche) que puede ser aplicado con *git apply*
 Para ver cambios desde hace 2 semanas, puedes intentar:
 
  $ git whatchanged --since="2 weeks ago"

es/branch.txt

@@ -4,13 +4,11 @@ El hacer branches (ramificar) y merges (unir) de manera instantánea, son dos de
 
 *Problema*: Factores externos necesitan inevitablemente de cambios de contexto.
 Un bug severo se manifiesta en la última versión sin previo aviso. El plazo para
-alguna prestación se acorta. Un desarrollador que tiene que ayudar en una sección indispensable
-del proyecto está por tomar licencia. En cualquier caso, debes soltar abruptamente lo que estás haciendo
-y enfocarte en una tarea completamente diferente.
+alguna prestación se acorta. Un desarrollador que tiene que ayudar en una sección indispensable del proyecto está por tomar licencia. En cualquier caso, debes soltar abruptamente lo que estás haciendo y enfocarte en una tarea completamente diferente.
 
 Interrumpir tu línea de pensamiento puede ser negativo para tu productividad, y cuanto más engorroso sea el cambiar contextos, mayor es la pérdida. Con los sistemas centralizados, debemos descargar una nueva copia. Los sistemas distribuídos se comportan mejor, dado que podemos clonar la versión deseada localmente.
 
-Pero el clonar igual implica copiar todo el directorio junto con toda la historia hasta el momento. Aunque Git reduce el costousando hard links y el compartir archivos, los archivos del proyecto deben ser recreados enteramente en el nuevo directorio.
+Pero el clonar igual implica copiar todo el directorio junto con toda la historia hasta el momento. Aunque Git reduce el costo de esta operación usando hard links y el compartir archivos, los archivos del proyecto deben ser recreados enteramente en el nuevo directorio.
 
 *Solución*: Git tiene una mejor herramienta para estas situaciones que es mucho más rápida y eficiente en tamaño que clonar *git branch*.
 
@@ -37,7 +35,7 @@ Parecería que sobreescribimos nuestro archivo y le hicimos commit. Pero es una
 
  $ git checkout master  # cambia a la versión original del archivo
 
-y presto! El archivo de texto es restaurado. Y si el jefe decide investigar este directorio, escribimos:
+y ¡presto! El archivo de texto es restaurado. Y si el jefe decide investigar este directorio, escribimos:
 
  $ git checkout jefe  # cambia a la versión adecuada para los ojos del jefe
 
@@ -49,7 +47,7 @@ Puedes cambiar entre ambas versiones del archivo cuantas veces quieras, y hacer
 Supongamos que estás trabajando en alguna prestación, y que por alguna razón, necesitas volver a una versión vieja y poner temporalmente algunos "print" para ver como funciona algo. Entonces:
 
  $ git commit -a
- $ git checkout SHA1_HASH
+ $ git checkout HASH_SHA1
 
 Ahora puedes agregar cualquier código temporal horrible por todos lados.
 Incluso puedes hacer commit de estos cambios. Cuando termines,
@@ -58,7 +56,7 @@ Incluso puedes hacer commit de estos cambios. Cuando termines,
 
 para volver a tu trabajo original. Observa que arrastrarás cualquier cambio del que no hayas hecho commit.
 
-¿Que pasa si quisieras cambiar los cambios temporales? Facil:
+¿Que pasa si quisieras cambiar los cambios temporales? Fácil:
 
  $ git checkout -b sucio
 
@@ -75,7 +73,7 @@ En otras palabras, luego de traer un estado viejo, Git automáticamente te pone
 Estás en medio de algo cuando te piden que dejes todo y soluciones un bug recién descubierto:
 
  $ git commit -a
- $ git checkout -b arreglos SHA1_HASH
+ $ git checkout -b arreglos HASH_SHA1
 
 Luego, una vez que solucionaste el bug:
 
@@ -132,7 +130,7 @@ Quizás quieras trabajar en todos los aspectos de un proyecto sobre la misma bra
 A continuación, trabaja en lo que sea: soluciona bugs, agrega prestaciones, agrega código temporal o lo que quieras, haciendo commits seguidos a medida que avanzas. Entonces:
 
   $ git checkout prolijo
-  $ git cherry-pick SHA1_HASH
+  $ git cherry-pick HASH_SHA1
 
 aplica un commit dado a la branch "prolijo". Con cherry-picks apropiados, puedes construir una rama que contenga solo el código permanente, y los commits relacionados juntos en un grupo.
 
@@ -164,7 +162,7 @@ para solucionar un bug de alta prioridad o algo.
 Es análogo a cambiar el canal de la TV temporalmente, para ver que otra
 cosa están dando. Pero en lugar de apretar un par de botones, tienes que
 crear, hacer checkout y eliminar branches y commits temporales. Por suerte,
-Git tiene un aatajo que es tan conveniente como un control remoto de TV:
+Git tiene un atajo que es tan conveniente como un control remoto de TV:
 
  $ git stash
 

es/clone.txt

@@ -1,8 +1,8 @@
 == Clonando  ==
 
-En sistemas de control de versiones antiguos, checkout es la operación standard para obtener archivos. Obtienes un conjunto de archivos en estado guardado que solicistaste.
+En sistemas de control de versiones antiguos, checkout es la operación standard para obtener archivos. Obtienes un conjunto de archivos en el estado guardado que solicitaste.
 
-En Git, y otros sistemas de control de versiones distribuídos, clonar es la operación standard. Para obtener archivos se crea un clon de un repositorio entero. En otras palabras, practicamente se crea una copia idéntica del servidor central. Todo lo que se pueda hacer en el repositorio principal, también podrás hacerlo.
+En Git, y otros sistemas de control de versiones distribuídos, clonar es la operación standard. Para obtener archivos se crea un clon de un repositorio entero. En otras palabras, prácticamente se crea una copia idéntica del servidor central. Todo lo que se pueda hacer en el repositorio principal, también podrás hacerlo.
 
 === Sincronizar Computadoras ===
 
@@ -33,7 +33,7 @@ y abre el Git daemon si es necesario:
  $ GIT_DIR=proj.git git init
  $ git daemon --detach  # podría ya estar corriendo
 
-Algunos servidores publicos, como http://repo.or.cz[repo.or.cz], tienen un método diferente para configurar el repositorio inicialmente vacío de Git, como llenar un formulario en una página.
+Algunos servidores públicos, como http://repo.or.cz[repo.or.cz], tienen un método diferente para configurar el repositorio inicialmente vacío de Git, como llenar un formulario en una página.
 
 Empuja (push) tu proyecto hacia el servidor central con:
 
@@ -79,9 +79,9 @@ Digamos que quieres trabajar en varias prestaciones a la vez. Haz commit de tu p
 
  $ git clone . /un/nuevo/directorio
 
-Git se aprovecha de los hard links y de compartir archivos de la manera mas segura posible para crear este clon, por lo que estará listo en un segundo, y podrás trabajar en dos prestaciones independientes de manera simultánea. Por ejemplo, puedes editar un clon mientras el otro está compilando.
+Gracias a los http://es.wikipedia.org/wiki/Enlace_duro[enlaces duros], los clones locales requieren menos tiempo y espacio que un backup plano.
 
-En cualquier momento, puedes hacer commit y pull de los cambios desde el otro clon.
+Ahora podrás trabajar en dos prestaciones independientes de manera simultánea. Por ejemplo, puedes editar un clon mientras el otro está compilando. En cualquier momento, puedes hacer commit y pull de los cambios desde el otro clon.
 
  $ git pull /el/otro/clon HEAD
 
@@ -110,4 +110,4 @@ Luego ve al nuevo directorio y escribe:
 El procedimiento para pasarle tus cambios a los demás depende de cuál es tu otro sistema de control de versiones. El nuevo directorio contiene los archivos con tus cambios. Ejecuta los comandos que sean necesarios para subirlos al repositorio central del otro sistema de control de versiones.
 
 El comando *git svn* automatiza lo anterior para repositorios de Subversion,
-y también puede ser usado para http://google-opensource.blogspot.com/2008/05/export-git-project-to-google-code.html[exportar un proyecto de Git a un repositorio de Subversion].
+y también puede ser usado para http://google-opensource.blogspot.com/ncr/2008/05/export-git-project-to-google-code.html[exportar un proyecto de Git a un repositorio de Subversion].

es/grandmaster.txt

@@ -40,7 +40,7 @@ No te preocupes, ejecuta:
 
  $ git add -p
 
-Por cada edición que hiciset, Git va a mostrar el pedazo de código que fue cambiado,
+Por cada edición que hiciste, Git va a mostrar el pedazo de código que fue cambiado,
 y preguntar si debería ser parte del próximo commit. Contesta con "y" o "n". 
 Hay otras opciones, como posponer la decisión; escribe "?" para saber más.
 
@@ -60,22 +60,18 @@ cual hace commit luego de que terminas.
 
 ==== Cambios en el 'stage' ====
 
-Hasta ahora hemos evitado el famoso 'indice' de git, pero ahora debermos enfrentarlo
-para explicar lo de arriba. El indice es un area temporal de montaje. Git evita enviar
+Hasta el momento hemos evitado el famoso 'indice' de git, pero ahora debemos enfrentarlo
+para explicar lo de arriba. El indice es un área temporal de montaje. Git evita enviar
 datos directamente entre tu proyecto y su historia. En su lugar, Git primero escribe datos
 al índice, y luego copia los datos del índice a su destino final.
 
 Por ejemplo, *commit -a* es en realidad un proceso de 2 pasos. El primer paso pone 
-una foto del estado actual de cada archivo administrado en el índice. El segundo paso
-graba de forma permanente esa foto que está en el índice. Un commit hecho sin *-a*
-solo efectúa el segundo paso, y solo tiene sentido luego de haber ejecutado comandos
-que de alguna forma alteran el índice, como *git add*.
+una instantánea del estado actual de cada archivo administrado en el índice. El segundo paso graba de forma permanente esa instantánea que está en el índice. Un commit hecho sin *-a* solo efectúa el segundo paso, y solo tiene sentido luego de haber ejecutado comandos que de alguna forma alteran el índice, como *git add*.
 
 Usualmente podemos ignorar el índice y pretender que estamos leyendo y escribiendo
 directo en la historia. En esta ocasión, queremos un control más fino de lo que se
-escribe en la historia, y nos vemos forzados a manipular el índice. Guardamos una foto de
-algunos, pero no todos, de nuestros cambios en el índice, y luego grabamos
-de forma permanenta esta instantánea cuidadosamente organizada.
+escribe en la historia, y nos vemos forzados a manipular el índice. Guardamos una instantánea de algunos, pero no todos, de nuestros cambios en el índice, y luego grabamos
+de forma permanente esta instantánea cuidadosamente organizada.
 
 === No Pierdas La Cabeza ===
 
@@ -105,7 +101,7 @@ Quizás ORIG_HEAD no es suficiente. Quizás acabas de descubrir que cometiste un
 y que hay que volver a un commit antiguo en una rama olvidada hace largo tiempo.
 
 Por defecto, Git guarda un commit por al menos 2 semanas, incluso si le ordenaste destruir
-la rama que lo contenía. El problema es encontra el hash apropiado. Podrías
+la rama que lo contenía. El problema es encontrar el hash apropiado. Podrías
 mirar todos los hashes en `.git/objects` y usar prueba y error para encontrar el que buscas.
 Pero hay una forma mucho más fácil.
 
@@ -133,7 +129,7 @@ Podrías querer configurar un periodo de gracia mayor para los commits condenado
   $ git config gc.pruneexpire "30 days"
 
 significa que un commmit eliminado se va a perder de forma permanente solo cuando
-hayan pasado 30 dáis y se ejecute *git gc*.
+hayan pasado 30 días y se ejecute *git gc*.
 
 También podrías querer deshabilitar invocaciones automáticas de *git gc*:
 
@@ -143,7 +139,7 @@ en cuyo caso los commits solo serán borrados cuando ejecutes *git gc* de forma
 
 === Construyendo sobre Git ===
 
-Siguiendo la tradición UNIX, el diseño de Git permite ser facilmente usado como un componente de bajo
+Siguiendo la tradición UNIX, el diseño de Git permite ser fácilmente usado como un componente de bajo
 nivel de otros programas, como GUI e interfaces web, interfaces de linea de comandos alternativas,
 herramientas de manejo de patches, herramientas de importación y conversión, etc.
 De hecho, algunos de los comandos de Git son ellos mismos scripts parados sobre los hombros de gigantes.
@@ -182,14 +178,14 @@ No hay necesidad de merges, push ni pull.
 
 === Acrobacias Peligrosas ===
 
-En estos dias, Git hace difícil que el usuario destruya datos de manera accidental.
+En estos días, Git hace difícil que el usuario destruya datos de manera accidental.
 Pero si sabes lo que estás haciendo, puedes hacer caso omiso de las trabas de seguridad para
 los comandos comunes.
 
 
 *Checkout*: Los cambios no commiteados hacen que checkout falle. Para destruir tus cambios, y hacer checkout de un commit dado, usa la opción de forzar:
 
-  $ git checkout -f COMMIT
+  $ git checkout -f HEAD^
 
 Por otro lado, si especificas una ruta específica para hacer checkout, no hay chequeos de seguridad.
 Las rutas suministradas son sobre-escritas de forma silenciosa.
@@ -201,14 +197,15 @@ Hay que tener cuidado al usar checkout de esta forma:
 
 *Branch*: El borrado de una rama falla si esto causa que se pierdan cambios, para forzarlo escribe:
 
-  $ git branch -D BRANCH  # en lugar de -d
+  $ git branch -D rama_muerta  # en lugar de -d
 
 De forma similar, intentar sobreescribir una rama moviendo otra, falla si esto resultase en pérdida de datos. Para forzar el mover una rama, corre:
 
   $ git branch -M [ORIGEN] DESTINO  # en lugar de -m
+
 A diferencia de checkout y reset, estos dos comandos evitan la destrucción de datos.
 Los cambios están aún guardados en el subdirectorio .git, y pueden obtenerse
-recuperando el has apropiado de `.git/logs` (ver "Cazando Cabezas" arriba).
+recuperando el hash apropiado de `.git/logs` (ver "Cazando Cabezas" arriba).
 Por defecto, serán guardados por al menos dos semanas.
 
 *Clean*: Algunos comandos de Git se rehúsan a proceder porque están preocupados
@@ -255,6 +252,6 @@ pare prevenirme de la desatención.
 Varias operaciones de git soportan hooks; ver *git help hooks*. Se pueden escribir
 hooks para quejarse de errores ortográficos en los mensajes de commit, agregar nuevos archivos,
 indentar párrafos, agregar una entrada en una página, reproducir un sonido, etc.
-
-Habíamos encontrado el hook *post-update* antes, cuando discutíamos como usar Git sobre HTTP.
-Este hook actualiza algunos archivos que Git necesita para comunicación no nativa.
+Habíamos activado el hook *post-update* antes, cuando discutíamos como usar Git sobre HTTP.
+Los hooks se ejecutan cada vez que la rama HEAD sufre cambios. Este hook en particular actualiza 
+algunos archivos que Git necesita para comunicación no nativa (como HTTP).

es/history.txt

@@ -1,7 +1,7 @@
 == Lecciones de Historia ==
 
 Una consecuencia de la naturaleza distribuída de git, es que la historia puede ser editada
-facilmente. Pero si manipulas el pasado, ten cuidado: solo reescribe la parte de
+fácilmente. Pero si manipulas el pasado, ten cuidado: solo reescribe la parte de
 la historia que solamente tú posees. Así como las naciones discuten eternamente sobre quién
 cometió qué atrocidad, si otra persona tiene un clon cuya versión de la historia
 difiere de la tuya, vas a tener problemas para reconciliar ambos árboles cuando éstos interactúen.
@@ -70,7 +70,7 @@ y los cambios oficiales. Preferirías ver todos tus cambios en una sección cont
 luego de todos los cambios oficiales.
 
 Lo descrito arriba es un trabajo para *git rebase*. En muchos casos se puede usar
-la bandera *--onto* y evitar la interacción.
+el parámetro *--onto* y evitar la interacción.
 
 Ver *git help rebase* para ejemplos detallados de este asombroso comando.
 Se pueden partir commits. Incluso se pueden reordenar las branches de un árbol.
@@ -112,34 +112,34 @@ un solo tiro.
 Como ejemplo, pega el texto a continuación en un archivo temporal, como ser `/tmp/history`:
 ----------------------------------
 commit refs/heads/master
-committer Alice <alice@example.com> Thu, 01 Jan 1970 00:00:00 +0000
+committer Alice <alice@ejemplo.com> Thu, 01 Jan 1970 00:00:00 +0000
 data <<EOT
-Initial commit.
+Commit inicial.
 EOT
 
 M 100644 inline hello.c
 data <<EOT
 #include <stdio.h>
 
 int main() {
-  printf("Hello, world!\n");
+  printf("Hola mundo!\n");
   return 0;
 }
 EOT
 
 
 commit refs/heads/master
-committer Bob <bob@example.com> Tue, 14 Mar 2000 01:59:26 -0800
+committer Bob <bob@ejemplo.com> Tue, 14 Mar 2000 01:59:26 -0800
 data <<EOT
-Replace printf() with write().
+Reemplazo printf() con write().
 EOT
 
 M 100644 inline hello.c
 data <<EOT
 #include <unistd.h>
 
 int main() {
-  write(1, "Hello, world!\n", 14);
+  write(1, "Hola mundo!\n", 14);
   return 0;
 }
 EOT
@@ -185,7 +185,7 @@ original escribiendo:
 
  $ git bisect reset
 
-En lugar de testear cada cambio a mano, automatiza la búsquea escribiendo:
+En lugar de testear cada cambio a mano, automatiza la búsqueda escribiendo:
 
  $ git bisect run COMANDO
 
@@ -243,7 +243,7 @@ revisar el e-mail o escribir documentación. A la hora de volver a la tarea orig
 el comando había terminado hace tiempo, y yo perdía más tiempo intentando recordar
 qué era lo que estaba haciendo. Los humanos no son buenos para el cambio de contexto.
 
-También había un interesante efecto tragediad-de-los-comunes: anticipando
+También ocurría un interesante efecto de "tragedia-de-los-comunes": anticipando
 la congestión de la red, la gente consume más ancho de banda que el necesario
 en varias operaciones, intentando anticipar futuras demoras. El esfuerzo combinado
 intensifica la congestión, alentando a las personas a consumir aún más ancho de banda