diff --git a/book/07-git-tools/sections/debugging.asc b/book/07-git-tools/sections/debugging.asc index bf65ddf8..7c44fb19 100644 --- a/book/07-git-tools/sections/debugging.asc +++ b/book/07-git-tools/sections/debugging.asc @@ -1,15 +1,15 @@ -=== Debugging with Git +=== Haciendo debug con Git -Git also provides a couple of tools to help you debug issues in your projects. -Because Git is designed to work with nearly any type of project, these tools are pretty generic, but they can often help you hunt for a bug or culprit when things go wrong. +Git también provee unas cuantas herramientas para realizar un debug a los problemas en tus proyectos. +Porque Git está diseñado para trabajar con casi cualquier tipo de proyecto, estas herramientas son bastante genéricas, pero pueden ayudar a cazar bugs o al culpable cuando las cosas salen mal. [[_file_annotation]] -==== File Annotation +==== Anotaciones de archivo -If you track down a bug in your code and want to know when it was introduced and why, file annotation is often your best tool. -It shows you what commit was the last to modify each line of any file. -So, if you see that a method in your code is buggy, you can annotate the file with `git blame` to see when each line of the method was last edited and by whom. -This example uses the `-L` option to limit the output to lines 12 through 22: +Si rastreas un bug en tu código y quieres saber cuándo fue introducido y por qué, la anotación de archivo será muchas veces tu mejor herramienta. +Esta te muestra qué commit fue el último en modificar cada línea de cualquier archivo. +Así que, si ves que un método en tu código tiene bugs, puedes anotar el archivo con `git blame` para ver cuándo cada línea del método fue editada por última vez y por quién. +Este ejemplo usa la opción `-L` para limitar la salida desde las líneas 12 a 22: [source,console] ---- @@ -27,19 +27,19 @@ $ git blame -L 12,22 simplegit.rb 42cf2861 (Magnus Chacon 2008-04-13 10:45:01 -0700 22) end ---- -Notice that the first field is the partial SHA-1 of the commit that last modified that line. -The next two fields are values extracted from that commit–the author name and the authored date of that commit – so you can easily see who modified that line and when. -After that come the line number and the content of the file. -Also note the `^4832fe2` commit lines, which designate that those lines were in this file’s original commit. -That commit is when this file was first added to this project, and those lines have been unchanged since. -This is a tad confusing, because now you’ve seen at least three different ways that Git uses the `^` to modify a commit SHA-1, but that is what it means here. +Nota que el primer campo es la parcial de SHA-1 del commit que modificó esa línea. +Los siguientes dos campos son valores extraídos del commit- el nombre del autor y la fecha del commit - así podrás ver de manera sencilla quién modificó esa línea y cuándo. +Tras estos viene el número de línea y el contenido del archivo. +También nota las líneas del commit `^4832fe2`, que designan que esas líneas estuvieron en el commit original del archivo. +Ese commit es cuando este archivo fue introducido por primera vez al proyecto, y esas líneas no han sido modificadas desde entonces. +Esto es un poco confuso, porque ahora has visto al menos tres maneras diferentes en que Git usa el `^` para modificar el SHA-1 de un commit, pero eso es lo que significa aquí. -Another cool thing about Git is that it doesn’t track file renames explicitly. -It records the snapshots and then tries to figure out what was renamed implicitly, after the fact. -One of the interesting features of this is that you can ask it to figure out all sorts of code movement as well. -If you pass `-C` to `git blame`, Git analyzes the file you’re annotating and tries to figure out where snippets of code within it originally came from if they were copied from elsewhere. -For example, say you are refactoring a file named `GITServerHandler.m` into multiple files, one of which is `GITPackUpload.m`. -By blaming `GITPackUpload.m` with the `-C` option, you can see where sections of the code originally came from: +Otra cosa interesante de Git es que no rastrea los nombres de archivos de forma explícita. +Registra las instantáneas y luego intenta averiguar lo que fue renombrado implícitamente, después del hecho. +Una de las características interesantes de esto es que se puede preguntar todo tipo de movimiento de código también. +Si pasas `-C` a` git blame`, Git analiza el archivo que estás anotando y trata de averiguar de dónde provienen originalmente fragmentos de código si se copiaron desde otro lugar. +Por ejemplo, digamos que estás modificando un archivo llamado `GITServerHandler.m` en múltiples archivos, uno de estos es `GITPackUpload.m`. +Realizando un blame a `GITPackUpload.m` con la opción `-C`, se puede ver de dónde vinieron las secciones del código: [source,console] ---- @@ -59,22 +59,23 @@ ad11ac80 GITPackUpload.m (Scott 2009-03-24 150) 56ef2caf GITServerHandler.m (Scott 2009-01-05 153) ---- -This is really useful. -Normally, you get as the original commit the commit where you copied the code over, because that is the first time you touched those lines in this file. -Git tells you the original commit where you wrote those lines, even if it was in another file. +Esto es realmente útil. +Normalmente, se obtiene como el commit original aquel de dónde se copió el código, porque esta es la primera vez en la que se tocaron estas líneas en el archivo. +Git te informa el commit original donde se escribieron esas líneas, incluso si esto fue hecho en otro archivo. [[_binary_search]] -==== Binary Search +==== Búsqueda binaria -Annotating a file helps if you know where the issue is to begin with. -If you don’t know what is breaking, and there have been dozens or hundreds of commits since the last state where you know the code worked, you’ll likely turn to `git bisect` for help. -The `bisect` command does a binary search through your commit history to help you identify as quickly as possible which commit introduced an issue. -Let’s say you just pushed out a release of your code to a production environment, you’re getting bug reports about something that wasn’t happening in your development environment, and you can’t imagine why the code is doing that. -You go back to your code, and it turns out you can reproduce the issue, but you can’t figure out what is going wrong. -You can bisect the code to find out. -First you run `git bisect start` to get things going, and then you use `git bisect bad` to tell the system that the current commit you’re on is broken. -Then, you must tell bisect when the last known good state was, using `git bisect good [good_commit]`: +Anotar un archivo ayuda si sabe dónde está el problema. +Si no sabes lo que está mal, y ha habido decenas o cientos de commits desde el último estado en el que sabes que funcionó el código, probablemente te recurrirás a `git bisect` para obtener ayuda. +El comando `bisect` hace una búsqueda binaria a través de su historial de commits para ayudarle a identificar lo más rápidamente posible qué commit introdujo un problema. + +Supongamos que acaba de emitir un release de su código en un entorno de producción, está recibiendo informes de errores sobre algo que no estaba ocurriendo en su entorno de desarrollo y no puede imaginar por qué el código lo está haciendo. +Regresa a su código, y resulta que puede reproducir el problema, pero no puede averiguar qué está pasando mal. +Puede biseccionar el código para averiguarlo. +Primero ejecuta `git bisect start` para hacer que las cosas funcionen, y luego usas` git bisect bad` para decirle al sistema que el commit actual está roto. +Entonces, debe decir a bisect cuándo fue el último estado bueno conocido, usando `git bisect good [good_commit]`: [source,console] ---- @@ -85,10 +86,10 @@ Bisecting: 6 revisions left to test after this [ecb6e1bc347ccecc5f9350d878ce677feb13d3b2] error handling on repo ---- -Git figured out that about 12 commits came between the commit you marked as the last good commit (v1.0) and the current bad version, and it checked out the middle one for you. -At this point, you can run your test to see if the issue exists as of this commit. -If it does, then it was introduced sometime before this middle commit; if it doesn’t, then the problem was introduced sometime after the middle commit. -It turns out there is no issue here, and you tell Git that by typing `git bisect good` and continue your journey: +Git se dio cuenta de que se produjeron alrededor de 12 commits entre el commit que marcó como el último commit bueno (v1.0) y la versión mala actual, y se comprobó el del medio para usted. +En este punto, puede ejecutar su prueba para ver si el problema existe a partir de este commit. +Si lo hace, entonces se introdujo en algún momento antes de este commit medio; Si no lo hace, entonces el problema se introdujo en algún momento después del commit del medio. +Resulta que no hay ningún problema aquí, y le dices a Git escribiendo `git bisect good` y continúa tu viaje: [source,console] ---- @@ -97,8 +98,8 @@ Bisecting: 3 revisions left to test after this [b047b02ea83310a70fd603dc8cd7a6cd13d15c04] secure this thing ---- -Now you’re on another commit, halfway between the one you just tested and your bad commit. -You run your test again and find that this commit is broken, so you tell Git that with `git bisect bad`: +Ahora estás en otro commit, a medio camino entre el que acabas de probar y tu mala comisión. +Ejecuta la prueba de nuevo y descubre que este commit está roto, por lo que le dices a Git que con `git bisect bad`: [source,console] ---- @@ -107,8 +108,8 @@ Bisecting: 1 revisions left to test after this [f71ce38690acf49c1f3c9bea38e09d82a5ce6014] drop exceptions table ---- -This commit is fine, and now Git has all the information it needs to determine where the issue was introduced. -It tells you the SHA-1 of the first bad commit and show some of the commit information and which files were modified in that commit so you can figure out what happened that may have introduced this bug: +Este commit está bien, y ahora Git tiene toda la información que necesita para determinar dónde se introdujo el problema. +Le dice que el SHA-1 del primer commit erróneo y muestra algo de la información del commit y qué archivos se modificaron en ese commit para que pueda averiguar qué sucedió que pueda haber introducido este error: [source,console] ---- @@ -124,17 +125,17 @@ Date: Tue Jan 27 14:48:32 2009 -0800 f24d3c6ebcfc639b1a3814550e62d60b8e68a8e4 M config ---- -When you’re finished, you should run `git bisect reset` to reset your HEAD to where you were before you started, or you’ll end up in a weird state: +Cuando haya terminado, debe ejecutar `git bisect reset` para reiniciar su HEAD a donde estaba antes de comenzar, o terminará en un estado raro: [source,console] ---- $ git bisect reset ---- -This is a powerful tool that can help you check hundreds of commits for an introduced bug in minutes. -In fact, if you have a script that will exit 0 if the project is good or non-0 if the project is bad, you can fully automate `git bisect`. -First, you again tell it the scope of the bisect by providing the known bad and good commits. -You can do this by listing them with the `bisect start` command if you want, listing the known bad commit first and the known good commit second: +Esta es una herramienta poderosa que puede ayudarle a comprobar cientos de commits para un bug introducido en cuestión de minutos. +De hecho, si tiene un script que retornará 0 si el proyecto está bien u otro número si el proyecto está mal, puede automatizar completamente `git bisect`. +En primer lugar, vuelva a decirle el alcance de la bisectriz, proporcionando los commits malos y buenos. +Puede hacerlo enumerándolos con el comando `bisect start` si lo desea, listando primero el commit malo conocido y el segundo el commit bueno conocido: [source,console] ---- @@ -142,5 +143,5 @@ $ git bisect start HEAD v1.0 $ git bisect run test-error.sh ---- -Doing so automatically runs `test-error.sh` on each checked-out commit until Git finds the first broken commit. -You can also run something like `make` or `make tests` or whatever you have that runs automated tests for you. +Hacerlo ejecuta automáticamente `test-error.sh` en cada commit de check-out hasta que Git encuentre el primer commit roto. +También puede ejecutar algo como `make` o ` make tests` o lo que sea que ejecute pruebas automatizadas para usted. diff --git a/status.json b/status.json index 2fb505a4..fbfa74fe 100644 --- a/status.json +++ b/status.json @@ -63,7 +63,7 @@ "sections/advanced-merging.asc": 100, "sections/bundling.asc": 0, "sections/credentials.asc": 0, - "sections/debugging.asc": 0, + "sections/debugging.asc": 100, "sections/interactive-staging.asc": 0, "sections/replace.asc": 0, "sections/rerere.asc": 0,