From 82cb344610309cc5f4110b29504cb1d713e12c6a Mon Sep 17 00:00:00 2001 From: Agustin Ferrari <2can@mail.ruu> Date: Fri, 14 Dec 2012 08:00:35 -0300 Subject: [PATCH] =?utf8?q?Realizo=20varias=20correcciones=20ortogr=C3=A1fi?= =?utf8?q?cas=20(y=20algunas=20gramaticales=20y=20de=20contexto)=20en=20to?= =?utf8?q?dos=20los=20archivos=20=20(menos=20en=20drawbacks.txt=20y=20span?= =?utf8?q?ish.txt),=20cambio=20"foto"=20por=20"instant=C3=A1nea"=20(me=20p?= =?utf8?q?arece=20que=20es=20una=20mejor=20traducci=C3=B3n=20para=20"snaps?= =?utf8?q?hot")=20y=20actualizo=20un=20p=C3=A1rrafo=20de=20clone.txt=20a?= =?utf8?q?=20partir=20de=20la=20version=20en=20ingles.=20Tambi=C3=A9n=20tr?= =?utf8?q?aduzco=20el=20ejemplo=20de=20la=20secci=C3=B3n=20"Haciendo=20His?= =?utf8?q?toria"=20de=20history.txt=20y=20los=20ejemplos=20que=20aparecen?= =?utf8?q?=20a=20lo=20largo=20de=20multiplayer.txt.?= MIME-Version: 1.0 Content-Type: text/plain; charset=utf8 Content-Transfer-Encoding: 8bit --- es/basic.txt | 8 ++++---- es/branch.txt | 18 ++++++++---------- es/clone.txt | 12 ++++++------ es/grandmaster.txt | 37 +++++++++++++++++------------------- es/history.txt | 20 +++++++++---------- es/intro.txt | 10 +++++----- es/multiplayer.txt | 56 +++++++++++++++++++++++++++--------------------------- es/preface.txt | 4 ++-- 8 files changed, 80 insertions(+), 85 deletions(-) diff --git a/es/basic.txt b/es/basic.txt index 1c1abd9..0831b91 100644 --- a/es/basic.txt +++ b/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. <> +- *`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. <> 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" diff --git a/es/branch.txt b/es/branch.txt index d152cbb..08a6750 100644 --- a/es/branch.txt +++ b/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 diff --git a/es/clone.txt b/es/clone.txt index 1914b9a..935bbda 100644 --- a/es/clone.txt +++ b/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]. diff --git a/es/grandmaster.txt b/es/grandmaster.txt index f4b0ee0..015984c 100644 --- a/es/grandmaster.txt +++ b/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). diff --git a/es/history.txt b/es/history.txt index 913737e..84f4d3e 100644 --- a/es/history.txt +++ b/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,9 +112,9 @@ 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 Thu, 01 Jan 1970 00:00:00 +0000 +committer Alice Thu, 01 Jan 1970 00:00:00 +0000 data < int main() { - printf("Hello, world!\n"); + printf("Hola mundo!\n"); return 0; } EOT commit refs/heads/master -committer Bob Tue, 14 Mar 2000 01:59:26 -0800 +committer Bob Tue, 14 Mar 2000 01:59:26 -0800 data < 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 diff --git a/es/intro.txt b/es/intro.txt index 471ca50..8ca2019 100644 --- a/es/intro.txt +++ b/es/intro.txt @@ -1,12 +1,12 @@ == Introducción == -Voy a usar una analogía para explicar el control de versiones. Mira http://es.wikipedia.org/wiki/Control_de_versiones[el artículo de wikipedia sobre control de versiones] para una explicación más cuerda. +Voy a usar una analogía para explicar el control de versiones. Mira http://es.wikipedia.org/wiki/Control_de_versiones[el artículo de Wikipedia sobre control de versiones] para una explicación más cuerda. === Trabajar Es Jugar === He jugado juegos de PC casi toda mi vida. En cambio, empecé a usar sistemas de control de versiones siendo adulto. Sospecho que no soy el único, y comparar ambas cosas puede hacer que estos conceptos sean más fáciles de explicar y entender. -Piensa en editar tu código o documento, o lo que sea, como si fuera jugar un juego. Una vez que progresaste mucho, te gustaría guardar. Para lograrlo, haces click en el botón de "Guardar" en tu editor de confianza. +Piensa en editar tu código o documento, o lo que sea, como si fuera jugar un juego. Una vez que progresaste mucho, te gustaría guardar. Para lograrlo, haces clic en el botón de "Guardar" en tu editor de confianza. Pero esto va a sobreescribir tu versión antigua. Es como esos viejos juegos que solo tenían un slot para guardar: se podía guardar, pero nunca podías volver a un estado anterior. Esto era una pena, porque tu versión anterior podía haber estado justo en una parte que era particularmente divertida, y podías querer volver a jugarla algún día. O peor aún, tu partida actual está en un estado donde es imposible ganar, y tienes que volver a empezar. @@ -14,7 +14,7 @@ Pero esto va a sobreescribir tu versión antigua. Es como esos viejos juegos que Cuando estás editando, puedes "Guardar Como..." un archivo diferente, o copiar el archivo a otro lugar antes de guardar si quieres probar versiones viejas. También puedes usar compresión para ahorrar espacio. Esta es una forma primitiva y muy trabajosa de control de versiones. Los videojuegos han mejorado esto hace ya tiempo, muchas veces permitiendo guardar en varios slots, fechados automáticamente. -Hagamos que el problema sea un poco más complejo. Imagina que tienes un montón de archivos que van juntos, como el código fuente de un proyecto, o archivos para un sitio web. Ahora, si quieres mantener una vieja versión, debes archivar un directorio completo. Tener muchar versiones a mano es inconveniente y rápidamente se vuelve costoso. +Hagamos que el problema sea un poco más complejo. Imagina que tienes un montón de archivos que van juntos, como el código fuente de un proyecto, o archivos para un sitio web. Ahora, si quieres mantener una vieja versión, debes archivar un directorio completo. Tener muchas versiones a mano es inconveniente y rápidamente se vuelve costoso. Con algunos juegos, una partida guardada en realidad consiste de un directorio lleno de archivos. Estos videojuegos ocultan este detalle del jugador y presentan una interfaz conveniente para administrar diferentes versiones de este directorio. @@ -22,7 +22,7 @@ Los sistemas de control de versiones no son diferentes. Todos tienen lindas inte === Control Distribuído === -Ahora imagina un juego muy difícil. Tan difícil para terminar, que muchos jugadores experientes alrededor del mundo deciden agruparse e intercambiar sus juegos guardados para intentar terminarlo. Los "Speedruns" son ejemplos de la vida real: los jugadores se especializan en diferents niveles del mismo juego y colaboran para lograr resultados sorprendentes. +Ahora imagina un juego muy difícil. Tan difícil para terminar, que muchos jugadores experimentados alrededor del mundo deciden agruparse e intercambiar sus juegos guardados para intentar terminarlo. Los "Speedruns" son ejemplos de la vida real: los jugadores se especializan en diferentes niveles del mismo juego y colaboran para lograr resultados sorprendentes. ¿Cómo armarías un sistema para que puedan descargar las partidas de los otros de manera simple? ¿Y para que suban las nuevas? Antes, cada proyecto usaba un control de versiones centralizado. Un servidor en algún lado contenía todos los juegos salvados. Nadie más los tenía. Cada jugador tenía a lo sumo un un par de juegos guardados en su máquina. Cuando un jugador quería progresar, obtenía la última versión del servidor principal, jugaba un rato, guardaba y volvía a subir al servidor para que todos los demás pudieran usarlo. @@ -39,7 +39,7 @@ Esta operación inicial de clonado, puede ser cara, especialmente si el historia Una creencia popular errónea es que los sistemas distribuídos son poco apropiados para proyectos que requieren un repositorio central oficial. Nada podría estar más lejos de la verdad. Fotografiar a alguien no hace que su alma sea robada, clonar el repositorio central no disminuye su importancia. -Una buena aproximación inicial, es que cualquier cosa que se puede hacer con un sistema de control de versiones centralizado, se puede hacer mejor con un sistema de versiones distribuído que esté bien diseñado. Los recursos de red son simplemente más costosos que los recursos locales. Aunque luego veremos que hay algunas desventajas para un sistema distribuído, hay menos probabilidad de hacer comparaciones erroneas al tener esto en cuenta. +Una buena aproximación inicial, es que cualquier cosa que se puede hacer con un sistema de control de versiones centralizado, se puede hacer mejor con un sistema de versiones distribuído que esté bien diseñado. Los recursos de red son simplemente más costosos que los recursos locales. Aunque luego veremos que hay algunas desventajas para un sistema distribuído, hay menos probabilidad de hacer comparaciones erróneas al tener esto en cuenta. Un proyecto pequeño, puede necesitar solo una fracción de de las características que un sistema así ofrece. Pero, ¿usarías números romanos si solo necesitas usar números pequeños?. Además, tu proyecto puede crecer más allá de tus expectativas originales. Usar Git desde el comienzo, es como llevar una navaja suiza, aunque solo pretendas usarla para abrir botellas. El día que necesites desesperadamente un destornillador, vas a agradecer el tener más que un simple destapador. diff --git a/es/multiplayer.txt b/es/multiplayer.txt index 9697c30..b625ce2 100644 --- a/es/multiplayer.txt +++ b/es/multiplayer.txt @@ -4,7 +4,7 @@ Inicialmente usaba Git en un proyecto privado donde yo era el único desarrollad Entre los comandos relacionados a la naturaleza distribuida de Git, sólo necesitaba *pull* y *clone* así yo podía mantener el mismo proyecto en diferentes lugares. -Más tarde quize publicar mi código con Git, e incluir cambios de los +Más tarde quise publicar mi código con Git, e incluir cambios de los contribuyentes. Tuve que aprender a administrar proyectos con múltiples desarrolladores de todo el mundo. Afortunadamente, esta es la fortaleza de Git, y podría decirse que su razón de ser. @@ -16,14 +16,14 @@ Por defecto, Git usa la configuración del sistema para rellenar estos campos. Para decirle explícitamente, escribe: $ git config --global user.name "John Doe" - $ git config --global user.email johndoe@example.com + $ git config --global user.email johndoe@ejemplo.com -Omite la bandera global para poner estas opciones sólo para el repositorio actual. +Omite el parámetro *--global* si quieres que estas opciones sólo sean aplicadas en el repositorio actual. === Git Sobre SSH, HTTP === Supón que tienes acceso SSH a un servidor web, pero Git no está instalado. Aunque -es menos eficiente que su protocolo nativo, Git se puede comuncar por HTTP. +es menos eficiente que su protocolo nativo, Git se puede comunicar por HTTP. Descarga, compila e instala Git en tu cuenta, y crea un repositorio en tu directorio web: @@ -39,11 +39,11 @@ En versiones antiguas de Git, el comando cp falla y debes ejecutar: Ahora tú puedes publicar tus últimas ediciones via SSH desde cualquier clon: - $ git push web.server:/path/to/proj.git master + $ git push servidor.web:/ruta/al/proyecto.git master y cualquiera puede obtener tu proyecto con: - $ git clone http://web.server/proj.git + $ git clone http://servidor.web/proyecto.git === Git Sobre Cualquier Cosa === @@ -53,34 +53,34 @@ fast-export* y *git fast-import* pueden convertir repositorios a un único archi y viceversa>>. Podríamos transportar tales archivos de ida y vuelta para enviar repositorios git sobre cualquier medio, pero una herramienta más eficiente es *git bundle*. -El emisor crea un 'paquete': +El emisor crea un 'bundle' (paquete): - $ git bundle create somefile HEAD + $ git bundle create algunarchivo HEAD -luego envía el paquete, +somefile+, a la otra parte de alguna forma: email, +Luego envía el paquete, +algunarchivo+, a la otra parte de alguna forma: email, pendrive, una impresión *xxd* y un escáner OCR, leyendo bits a través del teléfono, señales de humo, etc. El receptor recupera los commits del paquete escribiendo: - $ git pull somefile + $ git pull algunarchivo El receptor puede incluso hacer esto desde un repositorio vacío. A pesar de su -tamaño, +somefile+ contiene el repositorio git original completo. +tamaño, +algunarchivo+ contiene el repositorio git original completo. En proyectos más grandes, elimina la basura empaquetando sólo los cambios de los que -carece el otro repositorio. Por ejemplo, supón que el commit ``1b6d...'' es commit -compartido más reciente compartido por ambas partes: +carece el otro repositorio. Por ejemplo, supón que el commit ``1b6d...'' es el commit +más reciente compartido por ambas partes: - $ git bundle create somefile HEAD ^1b6d + $ git bundle create algunarchivo HEAD ^1b6d Si se hace a menudo, uno puede olvidar fácilmente cual commit fue el último enviado. La página de ayuda sugiere usar tags para resolver esto. Es decir, después de que envías un paquete, escribe: - $ git tag -f lastbundle HEAD + $ git tag -f ultimopaquete HEAD y crea nuevos paquetes de actualización con: - $ git bundle create newbundle HEAD ^lastbundle + $ git bundle create nuevopaquete HEAD ^ultimopaquete === Parches: La Moneda Global === @@ -138,7 +138,7 @@ cambiar o borrar este alias, pero usualmente no hay razón para hacerlo. Si el repositorio original se mueve, podemos actualizar la URL con: - $ git config remote.origin.url git://new.url/proj.git + $ git config remote.origin.url git://nueva.url/proyecto.git La opción +branch.master.merge+ especifica la rama remota por defecto en un *git pull*. Durante la clonación inicial, se configura a la rama actual del repositorio @@ -187,20 +187,20 @@ O puedes ver lo que ha sucedido con la rama ``experimental'': Supón que otros dos desarrolladores están trabajando en nuestro proyecto, y queremos mantener pestañas en ambos. Podemos seguir más de un repositorio a la vez con: - $ git remote add other git://example.com/some_repo.git - $ git pull other some_branch + $ git remote add otro git://ejemplo.com/algun_repositorio.git + $ git pull otro alguna_rama Ahora hemos mezclado una rama desde el segundo repositorio, y tenemos acceso fácil a todas las ramas de todos los repositorios: - $ git diff origin/experimental^ other/some_branch~5 + $ git diff origin/experimental^ otro/alguna_rama~5 -Pero ¿Qué pasa si queremos comparar sus cambios sin afectar nuestro propio trabajo? -En otras palabras, queremos examinar las ramas evitando que sis cambios invadan nuestro -directorio de trabajo. Entonces, en vez de pull, corre: +Pero, ¿qué pasa si queremos comparar sus cambios sin afectar nuestro propio trabajo? +En otras palabras, queremos examinar las ramas evitando que sus cambios invadan nuestro +directorio de trabajo. Entonces, en vez de pull, ejecuta: - $ git fetch # Fetch from origin, the default. - $ git fetch other # Fetch from the second programmer. + $ git fetch # Recuperamos desde el origen, por defecto. + $ git fetch otro # Recuperamos lo del segundo programador. Esto sólo obtiene historias. Aunque el directorio de trabajo permanece intacto, podemos referirnos a cualquier rama de cualquier repositorio en un comando Git @@ -220,14 +220,14 @@ los cuales voy a hacer pull. Algunos servicios de hosting Git te permiten hosped tu propia bifurcación de un proyecto con el clic de un botón. Después de que obtengo un árbol, uso comandos Git para navegar y examinar los cambios, -los que idealmente están bien organizados y biein descritos. Mezclo mis propios cambios, +los que idealmente están bien organizados y bien descritos. Mezclo mis propios cambios, y quizás hago más ediciones. Una vez satisfecho, los empujo al repositorio principal. Aunque rara vez recibo contribuciones, creo que este enfoque escala bien. Vea -http://torvalds-family.blogspot.com/2009/06/happiness-is-warm-scm.html [esta +http://torvalds-family.blogspot.com/ncr/2009/06/happiness-is-warm-scm.html[esta entrada de blog por Linus Torvalds]. Permanecer en el mundo Git es ligeramente más conveniente que parchar archivos, dado que me ahorra convertirlos a commits de Git. Además, Git maneja detalles como grabar el nombre y dirección de email del autor, así como la hora y fecha, y -le pide al autor desdribir sus propios cambios. +le pide al autor describir sus propios cambios. diff --git a/es/preface.txt b/es/preface.txt index d29ca52..ca175be 100644 --- a/es/preface.txt +++ b/es/preface.txt @@ -6,7 +6,7 @@ August 2007 http://git.or.cz/[Git] es la navaja suiza del control de versiones. Una herramienta de control de revisiones confiable, versátil y multipropósito, que por su extraordinaria flexibilidad es complicada de aprender, y más aún de dominar. Estoy documentando lo que he aprendido hasta ahora en estas páginas, porque inicialmente tuve dificultades para comprender http://www.kernel.org/pub/software/scm/git/docs/user-manual.html[el manual de usuario de Git]. -Tal como observó Arthur C. Clarke, cualquier tecnología suficientemente avanzada, es indistinguible de la magia. Este es un gran modo de acercarce a Git: los novatos pueden ignorar su funcionamiento interno, y ver a Git como un artefacto que puede asombrar a los amigos y enfurecer a los enemigos con sus maravillosas habilidades. +Tal como observó Arthur C. Clarke, cualquier tecnología suficientemente avanzada, es indistinguible de la magia. Este es un gran modo de acercarse a Git: los novatos pueden ignorar su funcionamiento interno, y ver a Git como un artefacto que puede asombrar a los amigos y enfurecer a los enemigos con sus maravillosas habilidades. En lugar de ser detallados, proveemos instrucciones generales para efectos particulares. Luego de un uso reiterado, gradualmente irás entendiendo como funciona cada truco, y como adaptar las recetas a tus necesidades. @@ -19,7 +19,7 @@ En lugar de ser detallados, proveemos instrucciones generales para efectos parti === Gracias! === -Agradezco a Dustin Sallings, Alberto Bertogli, James Cameron, Douglas Livingstone, Michael Budde, Richard Albury, Tarmigan, Derek Mahar y Frode Aannevik por sugerencias y mejoras. Gracias a Daniel Baumann por crear y mantener el paquete para Debian. También gracias a JunJie, Meng y JiangWei por la traduccción al chino. [Si me olvidé de tí, por favor recuérdamelo, porque suelo olvidarme de actualizar esta sección] +Agradezco a Dustin Sallings, Alberto Bertogli, James Cameron, Douglas Livingstone, Michael Budde, Richard Albury, Tarmigan, Derek Mahar y Frode Aannevik por sugerencias y mejoras. Gracias a Daniel Baumann por crear y mantener el paquete para Debian. También gracias a JunJie, Meng y JiangWei por la traducción al chino. [Si me olvidé de tí, por favor recuérdamelo, porque suelo olvidarme de actualizar esta sección] Estoy muy agradecido por todos los que me han dado apoyo y elogios. Me gustaría que este fuera un libro real impreso, para poder citar sus generosas palabras en la tapa a modo de promoción. Hablando en serio, aprecio enormemente cada mensaje. El leerlos siempre ilumina mi ánimo. -- 2.11.4.GIT