@@ -388,3 +388,45 @@ directories are expendable, then delete them mercilessly with: $ git clean -f -d Next time, that pesky command will work! + +=== Improve Your Public Image === + +Stupid mistakes abound in the histories of many of my projects. The most +frightening are missing files due to forgetting to run *git add*. Luckily I +have yet to lose crucial data though accidental omission because I rarely +delete original working directories. I typically notice the error a few commits +later, so the only damage is a bit of missing history and a sheepish admission +of guilt. + +I also regularly commit (literally and git-erally) the lesser transgression of +trailing whitespace. Though harmless, I wish these also never appeared on the +public record. + +In addition, though unscathed so far, I worry about leaving merge conflicts +unresolved. Usually I catch them when I build a project, but there are some +cases this can overlook. + +If only I had bought idiot insurance by using a _hook_ to alert me about these +problems: + + $ chmod +x .git/hooks/pre-commit + +Now Git aborts a commit if useless whitespace or unresolved merge conflicts are +detected. + +For a C project, add the following to the beginning of the *pre-commit* hook to +warn about forgotten files: + + if git ls-files -o | grep '\.[ch]$'; then + echo FAIL! Looks like you forgot to add some source files. + exit 1 + fi + +Several git operations support hooks; see *git help hooks*. One can write hooks +to complain about spelling mistakes in commit messages, add new files, indent +paragraphs, complain about lines over 80 characters long, add an entry to a +webpage, play a sound, and so on. + +In fact, we encountered the *post-update* hook while discussing Git over +HTTP: in this case, after the repository is updated, a hook script +maintains a few files Git needs for non-native communication. en/grandmaster.txt @@ -181,11 +181,12 @@ will always contain at least one line identifying a parent commit. There's little else to say. We have just exposed the secret behind Git's powers. It seems too simple: it looks like you could mix together a few shell -scripts and add a dash of C code to cook up the above in a matter of hours. In -fact, this accurately describes the earliest versions of Git. Nonetheless, -apart from ingenious packing tricks to save space, and ingenious indexing -tricks to save time, we now know how Git deftly changes a filesystem into a -database perfect for version control. +scripts and add a dash of C code to cook up the above in a matter of hours, +mixing in lock files and fsyncs for robustness. In fact, this accurately +describes the earliest versions of Git. Nonetheless, apart from ingenious +packing tricks to save space, and ingenious indexing tricks to save time, we +now know how Git deftly changes a filesystem into a database perfect for +version control. For example, if any file within the object database is corrupted by a disk error, then its hash will no longer match, alerting us to the problem. By en/secrets.txt @@ -59,7 +59,7 @@ te llevará al presente. También, para que Git no se queje, siempre haz un comm 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 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>> @@ -166,7 +166,7 @@ Siendo A, B, C, y D cuatro commits sucesivos, donde B es el mismo que A pero con Hay por lo menos tres soluciones. Asumiendo que estamos en D: 1. La diferencia entre A y B son los archivos eliminados. Podemos crear un patch representando esta diferencia y aplicarlo: - + $ git diff B A | git apply 2. Como en A tenemos los archivos guardados, podemos recuperarlos : es/basic.txt @@ -3,7 +3,7 @@ El hacer branches (ramificar) y merges (unir) de manera instantánea, son dos de las prestaciones más letales de Git. *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 +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. @@ -51,7 +51,7 @@ Supongamos que estás trabajando en alguna prestación, y que por alguna razón, $ git commit -a $ git checkout SHA1_HASH -Ahora puedes agregar cualquier código temporal horrible por todos lados. +Ahora puedes agregar cualquier código temporal horrible por todos lados. Incluso puedes hacer commit de estos cambios. Cuando termines, $ git checkout master @@ -91,7 +91,7 @@ Algunos proyectos requieren que tu código sea evaluado antes de que puedas subi ¿Que pasa si la segunda parte no puede ser escrita hasta que la primera sea aprobada y subida? En muchos sistemas de control de versiones, deberías enviar primero el código a los evaluadores, y luego esperar hasta que esté aprobado antes de empezar con la segunda parte. -En realidad, eso no es del todo cierto, pero en estos sistemas, editar la Parte II antes de subir la Parte I involucra sufrimiento e infortunio. En Git, los branches y merges son indoloros (un termino técnico que significa rápidos y locales). Entonces, luego de que hayas hecho commit de la primera parte y la hayas enviado a ser revisada: +En realidad, eso no es del todo cierto, pero en estos sistemas, editar la Parte II antes de subir la Parte I involucra sufrimiento e infortunio. En Git, los branches y merges son indoloros (un termino técnico que significa rápidos y locales). Entonces, luego de que hayas hecho commit de la primera parte y la hayas enviado a ser revisada: $ git checkout -b parte2 @@ -162,7 +162,7 @@ para salvar el estado actual y permitirte saltar a un estado anterior 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 +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: es/branch.txt @@ -23,7 +23,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. -¿Cómo armarías un sistema para que puedan descargar las partidas de los otros de manera simple? ¿Y para que suban las nuevas? +¿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 erroneas 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. es/intro.txt @@ -27,7 +27,7 @@ Estoy muy agradecido por todos los que me han dado apoyo y elogios. Me gustaría Esta guía se publica bajo la http://www.gnu.org/licenses/gpl-3.0.html[GNU General Public License versión 3]. Naturalmente, los fuentes se guardan en un repositorio Git, y pueden ser obtenidos escribiendo: - $ git clone git://repo.or.cz/gitmagic.git # Crea el directorio "gitmagic". + $ git clone git://repo.or.cz/gitmagic.git # Crea el directorio "gitmagic". Ver debajo por otros mirrors. @@ -36,4 +36,4 @@ Ver debajo por otros mirrors. - http://repo.or.cz/[http://repo.or.cz/] hospeda proyectos gratuitos, http://repo.or.cz/w/gitmagic.git[incluyendo esta guía]. - http://gitorious.org/[http://gitorious.org/] es un sitio que apunta al hosting de proyectos open-source. - - http://github.com/[http://github.com/] hospeda proyectos open-source gratis, http://github.com/blynn/gitmagic/tree/master[incluyendo esta guía], y proyectos privados por una cuota. + - http://github.com/[http://github.com/] hospeda proyectos open-source gratis, http://github.com/blynn/gitmagic/tree/master[incluyendo esta guía], y proyectos privados por una cuota. es/preface.txt 8ccfe9f31153016e3cdb81c035eb06e186def080 Ben Lynn benlynn@gmail.com http://github.com/blynn/gitmagic/commit/f6bc35cb239b3b9845ab5718b8fe49eee711bdb1 f6bc35cb239b3b9845ab5718b8fe49eee711bdb1 2009-06-25T01:51:08-07:00 2009-06-25T01:45:46-07:00 Wrote about hooks. Removed trailing whitespace. 1f8267fdeec2b4e35a906008dd4892a00a5cd7db Ben Lynn benlynn@gmail.com