Translated to Spanish the day39 file

2022/es/Days/day39.md

@@ -1,194 +1,190 @@
-## Viewing, unstaging, discarding & restoring
+## Visualización, desescalado, descarte y restauración
 
-Continuing from where we finished yesterday around some of the commands that we have with git and how to leverage git with your projects. Remember we have not touched GitHub or any other git-based services yet this is all to help you keep control of your projects locally at the moment, but they will all become useful when we start to integrate into those tools.
+Vamos a continuar donde lo dejamos ayer en torno a algunos de los comandos que tenemos con git y cómo aprovechar git con sus proyectos. Recuerde que no hemos tocado GitHub o cualquier otro servicio basado en git todavía, estamos viendo como mantener el control de los proyectos a nivel local por el momento, pero todos ellos serán útiles cuando empezamos a integrar esas herramientas.
 
-### Viewing the Staged and Unstaged Changes
+### Viendo los Cambios Staged y Unstaged
 
-It is good practice to make sure you view the staged and unstaged code before committing. We can do this by running the `git diff --staged` command
+Es una buena práctica asegurarse de ver el código preparado y no preparado antes de confirmar. Podemos hacerlo ejecutando el comando `git diff --staged`
 
 ![](Images/Day39_Git1.png)
 
-This then shows us all the changes we have made and all new files we have added or deleted.
+Esto nos muestra todos los cambios que hemos hecho y todos los archivos nuevos que hemos añadido o borrado.
 
-changes in the modified files are indicated with `---` or `+++` you can see below that we just added +add some text below which means they are new lines.
+Los cambios en los archivos modificados se indican con `---` o `+++` puedes ver abajo que acabamos de añadir +añadir algo de texto debajo lo que significa que son nuevas líneas.
 
 ![](Images/Day39_Git2.png)
 
-We can also run `git diff` to compare our staging area with our working directory. If we make some changes to our newly added file code.txt and add some lines of text.
+También podemos ejecutar `git diff` para comparar nuestra área de staging con nuestro directorio de trabajo. Si hacemos algunos cambios en nuestro archivo recién añadido code.txt y añadimos algunas líneas de texto.
 
 ![](Images/Day39_Git3.png)
 
-If we then run `git diff` we compare and see the output below.
+Si luego ejecutamos `git diff` comparamos y vemos la salida de abajo.
 
 ![](Images/Day39_Git4.png)
 
-### Visual Diff Tools
+### Herramientas visuales Diff
 
-For me, the above is more confusing so I would much rather use a visual tool,
-
-To name a few visual diff tools:
+Para mí, lo anterior es algo confuso, así que prefiero utilizar una herramienta visual. Por nombrar algunas de ellas:
 
 - KDiff3
 - P4Merge
-- WinMerge (Windows Only)
+- WinMerge (Sólo Windows)
 - VSCode
 
-To set this in git we run the following command `git config --global diff.tool vscode`
+Para configurar esto en git ejecutamos el siguiente comando `git config --global diff.tool vscode`.
 
-We are going to run the above and we are going to set some parameters when we launch VScode.
+Vamos a ejecutar lo anterior y vamos a establecer algunos parámetros cuando lancemos VScode.
 
 ![](Images/Day39_Git5.png)
 
-We can also check our configuration with `git config --global -e`
+También podemos comprobar nuestra configuración con `git config --global -e`.
 
 ![](Images/Day39_Git6.png)
 
-We can then use `git difftool` to now open our diff visual tool.
+Podemos usar `git difftool` para abrir nuestra herramienta visual diff.
 
 ![](Images/Day39_Git7.png)
 
-Which then opens our VScode editor on the diff page and compares the two, we have only modified one file from nothing to now adding a line of code on the right side.
+Esto abre nuestro editor VScode en la página diff y compara los dos. Veremos que sólo hemos modificado un archivo añadiendo una línea de código en el lado derecho.
 
 ![](Images/Day39_Git8.png)
 
-I find this method much easier to track changes and this is something similar to what we will see when we look into git-based services such as GitHub.
+Encuentro este método mucho más fácil para rastrear cambios y es algo similar a lo que veremos cuando busquemos en servicios basados en git como GitHub.
 
-We can also use `git difftool --staged` to compare stage with committed files.
+También podemos usar `git difftool --staged` para comparar el stage con los archivos confirmados.
 
 ![](Images/Day39_Git9.png)
 
-Then we can cycle through our changed files before we commit.
+Entonces podemos ver el ciclo a través de nuestros archivos cambiados antes de confirmar.
 
 ![](Images/Day39_Git10.png)
 
-I am using VScode as my IDE and like most IDEs they have this functionality built in it is very rare you would need to run these commands from the terminal, although helpful if you don't have an IDE installed for some reason.
+Estoy usando VScode como mi IDE y como la mayoría de los IDEs tienen esta funcionalidad incorporada. Es muy raro que necesites ejecutar estos comandos desde la terminal, aunque es útil si no tienes un IDE instalado por alguna razón.
 
-### Viewing the History
+### Viendo el Historial
 
-We previously touched on `git log` which will provide us with a comprehensive view of all commits we have made in our repository.
+Anteriormente hemos tocado `git log` que nos proporcionará una visión completa de todos los commits que hemos hecho en nuestro repositorio.
 
 ![](Images/Day39_Git11.png)
 
-Each commit has its hexadecimal string, unique to the repository. Here you can see which branch we are working on and then also the author, date and commit message.
+Cada commit tiene su cadena hexadecimal, única para el repositorio. Aquí puedes ver en qué rama estamos trabajando y también el autor, la fecha y el mensaje de confirmación.
 
-We also have `git log --oneline` and this gives us a much smaller version of the hexadecimal string which we can use in other `diff` commands. We also only have the one-line description or commit message.
+También tenemos `git log --oneline` que nos devuelve una versión mucho más pequeña de la cadena hexadecimal que podemos usar en otros comandos `diff`. También tenemos sólo la descripción de una línea o el mensaje de commit.
 
 ![](Images/Day39_Git12.png)
 
-We can reverse this into a start with the first commit by running `git log --oneline --reverse` and now we see our first commit at the top of our page.
+Podemos revertir esto en un inicio con el primer commit ejecutando `git log --oneline --reverse` y ahora vemos nuestro primer commit en la parte superior de nuestra página.
 
 ![](Images/Day39_Git13.png)
 
-### Viewing a Commit
+### Ver un commit
 
-Being able to look at the commit message is great if you have been conscious about following best practices and you have added a meaningful commit message, however, there is also `git show` command which allows us to inspect and view a commit.
-
-We can use `git log --oneline --reverse` to get a list of our commits. and then we can take those and run `git show <commit ID>`
+Ser capaz de mirar el mensaje de confirmación es genial si has sido consciente de seguir las mejores prácticas y has añadido un mensaje de confirmación significativo, sin embargo, también existe el comando `git show` si queremos inspeccionar un commit concreto. Podemos utilizar `git log --oneline --reverse` para obtener una lista de nuestros commits. y luego podemos tomarlos y ejecutar `git show <commit ID>`.
 
 ![](Images/Day39_Git14.png)
 
-The output of that command will look like below with the detail of the commit, author and what changed.
+La salida de ese comando se verá como abajo con el detalle del commit, autor y lo que cambió.
 
 ![](Images/Day39_Git15.png)
 
-We can also use `git show HEAD~1` where 1 is how many steps back from the current version we want to get back to.
+También podemos usar `git show HEAD~1` donde 1 es el número de pasos hacia atrás desde la versión actual a la que queremos volver.
 
-This is great if you want some detail on your files, but if we want to list all the files in a tree for the whole snapshot directory. We can achieve this by using the `git ls-tree HEAD~1` command, again going back one snapshot from the last commit. We can see below we have two blobs, these indicate files whereas the tree would indicate a directory. You can also see commits and tags in this information.
+Esto es genial si queremos algún detalle de nuestros archivos, pero si queremos listar todos los archivos de un árbol para todo el directorio de la instantánea. Podemos conseguirlo usando el comando `git ls-tree HEAD~1`, de nuevo retrocediendo una instantánea desde el último commit. Podemos ver abajo que tenemos dos blobs, estos indican archivos mientras que el árbol indicaría un directorio. También puedes ver commits y tags en esta información.
 
 ![](Images/Day39_Git16.png)
 
-We can then use the above to drill in and see the contents of our file (blobs) using the `git show` command.
+Podemos usar lo anterior para ver el contenido de nuestro archivo (blobs) usando el comando `git show`.
 
 ![](Images/Day39_Git17.png)
 
-Then the contents of that specific version of the file will be shown.
+Entonces se mostrará el contenido de esa versión específica del archivo.
 
 ![](Images/Day39_Git18.png)
 
-### Unstaging Files
+### Unstaging archivos
 
-There will be a time when you have maybe used `git add .` but there are files you do not wish to commit to that snapshot just yet. In this example below I have added newfile.txt to my staging area but I am not ready to commit this file so I am going to use the `git restore --staged newfile.txt` to undo the `git add` step.
+Habrá un momento en el que quizás haya usado `git add .` pero hay archivos que no desea confirmar en esa instantánea todavía. En este ejemplo he añadido newfile.txt a mi área de staging pero no estoy listo para confirmar este archivo así que voy a usar `git restore --staged newfile.txt` para deshacer el paso `git add`.
 
 ![](Images/Day39_Git19.png)
 
-We can also do the same to modified files such as main.js and unstage the commit, see above we have a greem M for modified and then below we are unstaging those changes.
+También podemos hacer lo mismo con archivos modificados como main.js y deshacer el commit, mira arriba tenemos una M en verde y abajo hemos deshecho esos cambios.
 
 ![](Images/Day39_Git20.png)
 
-I have found this command quite useful during the 90DaysOfDevOps as I sometimes work ahead of the days where I feel I want to make notes for the following day but I don't want to commit and push to the public GitHub repository.
+He encontrado este comando bastante útil durante los 90DaysOfDevOps ya que a veces trabajo antes de los días en los que siento que quiero hacer anotaciones para el día siguiente pero no quiero hacer commit y push al repositorio público de GitHub.
 
-### Discarding Local Changes
+### Descartando Cambios Locales
 
-Sometimes we might make changes but we are not happy with those changes and we want to throw them away. We are going to use the `git restore` command again and we are going to be able to restore files from our snapshots or previous versions. We can run `git restore .` against our directory and we will restore everything from our snapshot but notice that our untracked file is still present. There is no previous file being tracked called newfile.txt.
+A veces podemos hacer cambios pero no estamos contentos con esos cambios y queremos desecharlos. Vamos a utilizar el comando `git restore` de nuevo y vamos a poder restaurar archivos de nuestras snapshots o versiones anteriores. Podemos ejecutar `git restore .` contra nuestro directorio y restauraremos todo desde nuestra instantánea, pero observa que nuestro archivo no rastreado sigue presente. No hay ningún archivo anterior siendo rastreado llamado newfile.txt.
 
 ![](Images/Day39_Git21.png)
 
-Now to remove newfile.txt or any untracked files. We can use `git clean` we will get a warning alone.
+Ahora para eliminar newfile.txt o cualquier archivo no rastreado. Podemos usar `git clean` solo obtendremos una advertencia.
 
 ![](Images/Day39_Git22.png)
 
-Or if we know the consequences then we might want to run `git clean -fd` to force and remove all directories.
+O si conocemos las consecuencias podemos ejecutar `git clean -fd` para forzar y eliminar todos los directorios.
 
 ![](Images/Day39_Git23.png)
 
-### Restoring a File to an Earlier Version
+### Restaurar un archivo a una versión anterior
 
-As we have alluded to throughout a big portion of what Git can help with is being able to restore copies of your files from your snapshots (this is not a backup but it is a very fast restore point) My advice is that you also save copies of your code in other locations using a backup solution for this.
+Como hemos aludido, lo que Git nos puede ayudar es a restaurar copias de tus archivos desde tus instantáneas (esto no es una copia de seguridad, pero es un punto de restauración muy rápido). Es recomendable que también guardes copias de tu código en otros lugares utilizando una solución de copia de seguridad expresamente para esto.
 
-As an example let's go and delete our most important file in our directory, notice we are using Unix-based commands to remove this from the directory, not git commands.
+Como ejemplo vamos a borrar nuestro archivo más importante en nuestro directorio, pero utilizando comandos basados en Unix para eliminar el directorio, no comandos de git.
 
 ![](Images/Day39_Git24.png)
 
-Now we have no readme.mdin our working directory. We could have used `git rm readme.md` and this would then be reflected in our git database. Let's also delete it from here to simulate it being removed completely.
+Ahora no tenemos readme.md en nuestro directorio de trabajo. Podríamos haber usado `git rm readme.md` y esto se reflejaría en nuestra base de datos de git. Así que lo borramos también así para simular la eliminación por completo.
 
 ![](Images/Day39_Git25.png)
 
-Let's now commit this with a message and prove that we no longer have anything in our working directory or staging area.
+Ahora confirmemos esto con un mensaje y probemos que ya no tenemos nada en nuestro directorio de trabajo o área de preparación.
 
 ![](Images/Day39_Git26.png)
 
-Mistakes were made and we now need this file back!
+¡Se cometieron errores y ahora necesitamos recuperar ese archivo! 😱
 
-We could use the `git undo` command which will undo the last commit, but what if it was a while back? We can use our `git log` command to find our commits and then we find that our file is in the last commit but we don't all of those commits to be undone so we can then use this command `git restore --source=HEAD~1 README.md` to specifically find the file and restore it from our snapshot.
+Podríamos usar el comando `git undo` que deshará el último commit, pero ¿qué pasa si fue hace tiempo? Podemos usar nuestro comando `git log` para encontrar el commit concreto pero no queremos que todos los commits que haya por el medio se deshagan, así que vamos a especificar el fichero con el comando `git restore --source=HEAD~1 README.md` y restaurarlo desde nuestro snapshot.
 
-You can see using this process we now have the file back in our working directory.
+Puedes ver que usando este proceso ahora tenemos el archivo de vuelta en nuestro directorio de trabajo 😅
 
 ![](Images/Day39_Git27.png)
 
-We now have a new untracked file and we can use our commands previously mentioned to track, stage and commit our files and changes.
+Ahora tenemos un nuevo archivo no rastreado y podemos usar los comandos mencionados anteriormente para rastrear, preparar y comitear nuestros cambios.
 
 ### Rebase vs Merge
 
-This seems to be the biggest headache when it comes to Git and when to use rebase vs using merge on your git repositories.
+Este parece ser el mayor dolor de cabeza cuando se trata de Git, cuando usar rebase o merge en tus repositorios git.
 
-The first thing to know is that both `git rebase` and `git merge` solve the same problem. Both are to integrate changes from one branch into another branch. However, they do this in different ways.
+Lo primero que hay que saber es que tanto `git rebase` como `git merge` resuelven el mismo problema. Ambos sirven para integrar cambios de una rama en otra rama. Sin embargo, lo hacen de formas diferentes.
 
-Let's start with a new feature in a new dedicated branch. The Main branch continues with new commits.
+Empecemos con una nueva característica en una nueva rama dedicada. La rama principal continúa con nuevos commits.
 
 ![](Images/Day39_Git28.png)
 
-The easy option here is to use `git merge feature main` which will merge the main branch into the feature branch.
+La opción fácil es usar `git merge feature main` que fusionará la rama principal en la rama feature.
 
 ![](Images/Day39_Git29.png)
 
-Merging is easy because it is non-destructive. The existing branches are not changed in any way. However, this also means that the feature branch will have an irrelevant merge commit every time you need to incorporate upstream changes. If the main is very busy or active this will or can pollute the feature branch history.
+La fusión es fácil porque no es destructiva. Las ramas existentes no se modifican. Sin embargo, esto también significa que la rama principal tendrá un commit de fusión irrelevante cada vez que necesites incorporar cambios de la rama principal. Si la main está muy ocupada o activa esto podría contaminar el historial de la rama feature.
 
-As an alternate option, we can rebase the feature branch onto the main branch using
+Como opción alternativa, podemos volver a basar la rama de características en la rama principal utilizando:
 
 ```
 git checkout feature
 git rebase main
 ```
 
-This moves the feature branch (the entire feature branch) effectively incorporating all of the new commits in the main. But, instead of using a merge commit, rebasing re-writes the project history by creating brand new commits for each commit in the original branch.
+Esto mueve la rama feature (toda la rama feature) incorporando efectivamente todos los nuevos commits en la main. Pero, en lugar de usar un commit merge, rebasing reescribe la historia del proyecto creando nuevos commits para cada commit en la rama original.
 
 ![](Images/Day39_Git30.png)
 
-The biggest benefit of rebasing is a much cleaner project history. It also eliminates unnecessary merge commits. and as you compare the last two images, you can follow arguably a much cleaner linear project history.
+El mayor beneficio de rebase es un historial del proyecto mucho más limpio. También elimina commits de fusión innecesarios. Si comparas las dos últimas imágenes, puedes seguir una historia del proyecto lineal mucho más limpia.
 
-Although it's still not a foregone conclusion, choosing the cleaner history also comes with tradeoffs, If you do not follow the [The Golden rule of rebasing](https://www.atlassian.com/git/tutorials/merging-vs-rebasing#the-golden-rule-of-rebasing) re-writing project history can be potentially catastrophic for your collaboration workflow. And, less importantly, rebasing loses the context provided by a merge commit—you can’t see when upstream changes were incorporated into the feature.
+Aunque todavía no es una conclusión inevitable, la elección del historial más limpio también viene con desventajas, si no sigues [La regla de oro de rebasing](hhttps://www.atlassian.com/git/tutorials/merging-vs-rebasing#the-golden-rule-of-rebasing) y vuelves a escribir el historial del proyecto puede ser potencialmente catastrófico para su flujo de trabajo de colaboración. Y por otro lado, con menos importancia pero también presente, al realizar rebase se pierde el contexto proporcionado por un commit de fusión: no puedes ver cuándo se incorporaron realmente los cambios de la línea ascendente en la feature.
 
-## Resources
+## Recursos
 
 - [What is Version Control?](https://www.youtube.com/watch?v=Yc8sCSeMhi4)
 - [Types of Version Control System](https://www.youtube.com/watch?v=kr62e_n6QuQ)
@@ -198,5 +194,13 @@ Although it's still not a foregone conclusion, choosing the cleaner history also
 - [Complete Git and GitHub Tutorial](https://www.youtube.com/watch?v=apGV9Kg7ics)
 - [Git cheatsheet](https://www.atlassian.com/git/tutorials/atlassian-git-cheatsheet)
 - [Exploring the Git command line – A getting started guide](https://veducate.co.uk/exploring-the-git-command-line/)
+- [En español] [Comandos Git](https://gitea.vergaracarmona.es/man-linux/comandos-git)
+- [En español][Apuntes Curso de Git](https://vergaracarmona.es/wp-content/uploads/2022/10/Curso-git_vergaracarmona.es_.pdf) de [Juan Carlos Rubio](https://www.linkedin.com/in/juan-carlos-rubio-pineda/Curso-git_vergaracarmona-es).
+- [En español] En los [apuntes](https://vergaracarmona.es/apuntes/) del traductor:
+  - ["Instalar git en ubuntu"](https://vergaracarmona.es/instalar-git-en-ubuntu/)
+  - ["Comandos de git"](https://vergaracarmona.es/comandos-de-git/)
+  - ["Estrategias de fusión en git: Ship / Show / Ask"](https://vergaracarmona.es/estrategias-bifurcacion-git-ship-show-ask/)
+  - ["Resolver conflictos en Git. Merge, Squash, Rebase o Pull"](https://vergaracarmona.es/merge-squash-rebase-pull/)
+  - ["Borrar commits de git: reset, rebase y cherry-pick"](https://vergaracarmona.es/reset-rebase-cherry-pick/)
 
-See you on [Day40](day40.md)
+Nos vemos en el [Día 40](day40.md)