diff --git a/.tx/config b/.tx/config new file mode 100644 index 0000000000..8d3784a9aa --- /dev/null +++ b/.tx/config @@ -0,0 +1,86 @@ +[main] +host = https://www.transifex.com + +[git-novice-es.01-basics-md] +file_filter = _episodes_/01-basics.md +source_file = _episodes/01-basics.md +source_lang = en +type = GITHUBMARKDOWN + +[git-novice-es.02-setup-md] +file_filter = _episodes_/02-setup.md +source_file = _episodes/02-setup.md +source_lang = en +type = GITHUBMARKDOWN + +[git-novice-es.03-create-md] +file_filter = _episodes_/03-create.md +source_file = _episodes/03-create.md +source_lang = en +type = GITHUBMARKDOWN + +[git-novice-es.04-changes-md] +file_filter = _episodes_/04-changes.md +source_file = _episodes/04-changes.md +source_lang = en +type = GITHUBMARKDOWN + +[git-novice-es.05-history-md] +file_filter = _episodes_/05-history.md +source_file = _episodes/05-history.md +source_lang = en +type = GITHUBMARKDOWN + +[git-novice-es.06-ignore-md] +file_filter = _episodes_/06-ignore.md +source_file = _episodes/06-ignore.md +source_lang = en +type = GITHUBMARKDOWN + +[git-novice-es.07-github-md] +file_filter = _episodes_/07-github.md +source_file = _episodes/07-github.md +source_lang = en +type = GITHUBMARKDOWN + +[git-novice-es.08-collab-md] +file_filter = _episodes_/08-collab.md +source_file = _episodes/08-collab.md +source_lang = en +type = GITHUBMARKDOWN + +[git-novice-es.09-conflict-md] +file_filter = _episodes_/09-conflict.md +source_file = _episodes/09-conflict.md +source_lang = en +type = GITHUBMARKDOWN + +[git-novice-es.10-open-md] +file_filter = _episodes_/10-open.md +source_file = _episodes/10-open.md +source_lang = en +type = GITHUBMARKDOWN + +[git-novice-es.11-licensing-md] +file_filter = _episodes_/11-licensing.md +source_file = _episodes/11-licensing.md +source_lang = en +type = GITHUBMARKDOWN + +[git-novice-es.12-citation-md] +file_filter = _episodes_/12-citation.md +source_file = _episodes/12-citation.md +source_lang = en +type = GITHUBMARKDOWN + +[git-novice-es.13-hosting-md] +file_filter = _episodes_/13-hosting.md +source_file = _episodes/13-hosting.md +source_lang = en +type = GITHUBMARKDOWN + +[git-novice-es.14-supplemental-rstudio-md] +file_filter = _episodes_/14-supplemental-rstudio.md +source_file = _episodes/14-supplemental-rstudio.md +source_lang = en +type = GITHUBMARKDOWN diff --git a/CONDUCT.md b/CONDUCT.md index 5e4943b4ca..65d23e6d0e 100644 --- a/CONDUCT.md +++ b/CONDUCT.md @@ -1,45 +1,45 @@ --- layout: page -title: "Contributor Code of Conduct" +title: "Código de conducta del contribuyente" permalink: /conduct/ --- -As contributors and maintainers of this project, -we pledge to respect all people who contribute through reporting issues, -posting feature requests, -updating documentation, -submitting pull requests or patches, -and other activities. +Los contribuyentes y mantenedores de este proyecto, +nos comprometemos a respetar a todas las personas que contribuyen a través de problemas de informes, +publicar solicitudes de características, +actualizar la documentación, +enviando solicitudes de extracción o parches, +y otras actividades. -We are committed to making participation in this project a harassment-free experience for everyone, -regardless of level of experience, -gender, -gender identity and expression, -sexual orientation, -disability, -personal appearance, -body size, -race, -ethnicity, -age, -or religion. +Nos comprometemos a hacer que la participación en este proyecto sea una experiencia libre de acoso para todos, +independientemente del nivel de experiencia, +género, +identidad y expresión de género, +orientación sexual, +discapacidad, +apariencia personal, +tamaño corporal, +carrera, +etnia, +años, +o religión. -Examples of unacceptable behavior by participants include the use of sexual language or imagery, -derogatory comments or personal attacks, +Los ejemplos de comportamiento inaceptable de los participantes incluyen el uso de imágenes o lenguaje sexual, +comentarios despectivos o ataques personales, trolling, -public or private harassment, -insults, -or other unprofessional conduct. +acoso público o privado, +insultos, +u otra conducta no profesional. -Project maintainers have the right and responsibility to remove, edit, or reject -comments, commits, code, wiki edits, issues, and other contributions -that are not aligned to our [Code of Conduct][coc]. -Project maintainers who do not follow the Code of Conduct may be removed from the project team. +Los mantenedores de proyectos tienen el derecho y la responsabilidad de eliminar, editar o rechazar +comentarios, commits, código, ediciones de wiki, problemas y otras contribuciones +que no están alineados con nuestro [Código de Conducta][coc]. +Los mantenedores del proyecto que no sigan el Código de Conducta pueden ser removidos del equipo del proyecto. -Instances of abusive, harassing, or otherwise unacceptable behavior -may be reported by following our [reporting guidelines][coc-reporting]. +Instancias de comportamiento abusivo, acosador o de otra manera inaceptable +puede informarse siguiendo nuestras [guías de informes][coc-reporting]. -- [Software and Data Carpentry Code of Conduct][coc] -- [Code of Conduct Reporting Guide][coc-reporting] +- [Código de conducta de Software y Data Carpentry][coc] +- [Guía de informes del código de conducta][coc-reporting] {% include links.md %} diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 9e040076b5..583edfc211 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,141 +1,109 @@ -# Contributing - -[Software Carpentry][swc-site] and [Data Carpentry][dc-site] are open source projects, -and we welcome contributions of all kinds: -new lessons, -fixes to existing material, -bug reports, -and reviews of proposed changes are all welcome. - -## Contributor Agreement - -By contributing, -you agree that we may redistribute your work under [our license](LICENSE.md). -In exchange, -we will address your issues and/or assess your change proposal as promptly as we can, -and help you become a member of our community. -Everyone involved in [Software Carpentry][swc-site] and [Data Carpentry][dc-site] -agrees to abide by our [code of conduct](CONDUCT.md). - -## How to Contribute - -The easiest way to get started is to file an issue -to tell us about a spelling mistake, -some awkward wording, -or a factual error. -This is a good way to introduce yourself -and to meet some of our community members. - -1. If you do not have a [GitHub][github] account, - you can [send us comments by email][contact]. - However, - we will be able to respond more quickly if you use one of the other methods described below. - -2. If you have a [GitHub][github] account, - or are willing to [create one][github-join], - but do not know how to use Git, - you can report problems or suggest improvements by [creating an issue][new-issue]. - This allows us to assign the item to someone - and to respond to it in a threaded discussion. - -3. If you are comfortable with Git, - and would like to add or change material, - you can submit a pull request (PR). - Instructions for doing this are [included below](#using-github). - -## Where to Contribute - -1. If you wish to change this lesson, - please work in , - which can be viewed at . - -2. If you wish to change the example lesson, - please work in , - which documents the format of our lessons - and can be viewed at . - -3. If you wish to change the template used for workshop websites, - please work in . - The home page of that repository explains how to set up workshop websites, - while the extra pages in - provide more background on our design choices. - -4. If you wish to change CSS style files, tools, - or HTML boilerplate for lessons or workshops stored in `_includes` or `_layouts`, - please work in . - -## What to Contribute - -There are many ways to contribute, -from writing new exercises and improving existing ones -to updating or filling in the documentation -and submitting [bug reports][new-issue] -about things that don't work, aren't clear, or are missing. -If you are looking for ideas, -please see [the list of issues for this repository][issues], -or the issues for [Data Carpentry][dc-issues] -and [Software Carpentry][swc-issues] projects. - -Comments on issues and reviews of pull requests are just as welcome: -we are smarter together than we are on our own. -Reviews from novices and newcomers are particularly valuable: -it's easy for people who have been using these lessons for a while -to forget how impenetrable some of this material can be, -so fresh eyes are always welcome. - -## What *Not* to Contribute - -Our lessons already contain more material than we can cover in a typical workshop, -so we are usually *not* looking for more concepts or tools to add to them. -As a rule, -if you want to introduce a new idea, -you must (a) estimate how long it will take to teach -and (b) explain what you would take out to make room for it. -The first encourages contributors to be honest about requirements; -the second, to think hard about priorities. - -We are also not looking for exercises or other material that only run on one platform. -Our workshops typically contain a mixture of Windows, Mac OS X, and Linux users; -in order to be usable, -our lessons must run equally well on all three. - -## Using GitHub - -If you choose to contribute via GitHub, -you may want to look at -[How to Contribute to an Open Source Project on GitHub][how-contribute]. -In brief: - -1. The published copy of the lesson is in the `gh-pages` branch of the repository - (so that GitHub will regenerate it automatically). - Please create all branches from that, - and merge the [master repository][repo]'s `gh-pages` branch into your `gh-pages` branch - before starting work. - Please do *not* work directly in your `gh-pages` branch, - since that will make it difficult for you to work on other contributions. - -2. We use [GitHub flow][github-flow] to manage changes: - 1. Create a new branch in your desktop copy of this repository for each significant change. - 2. Commit the change in that branch. - 3. Push that branch to your fork of this repository on GitHub. - 4. Submit a pull request from that branch to the [master repository][repo]. - 5. If you receive feedback, - make changes on your desktop and push to your branch on GitHub: - the pull request will update automatically. - -Each lesson has two maintainers who review issues and pull requests -or encourage others to do so. -The maintainers are community volunteers, -and have final say over what gets merged into the lesson. - -## Other Resources - -General discussion of [Software Carpentry][swc-site] and [Data Carpentry][dc-site] -happens on the [discussion mailing list][discuss-list], -which everyone is welcome to join. -You can also [reach us by email][contact]. - -[contact]: mailto:admin@software-carpentry.org +# Contribuyendo + +[Software Carpentry][swc-site] y [Data Carpentry][dc-site] son ​ +proyectos de código abierto, y damos la bienvenida a contribuciones +de todo tipo: nuevas lecciones, correcciones al material existente, +informes de errores, y revisiones de los cambios propuestos son todas +bienvenidas. + +## Acuerdo de Colaborador + +Al contribuir, tú aceptas que podemos redistribuir su trabajo bajo +[nuestra licencia](LICENCIA.md). A cambio, abordaremos tus problemas +y/o evaluaremos tu propuesta de cambio tan pronto como podamos, y +te ayudaremos a convertirte en miembro de nuestra comunidad. Todos los +involucrados en [Software Carpentry][swc-site] y +[Data Carpentry][dc-site] +aceptan cumplir con nuestro [código de conducta](CONDUCT.md). + +## Cómo contribuir + +La forma más fácil de comenzar es presentar un problema para +poder corregirlo, como un error ortográfico, algunas palabras no claras, +o un error fáctico. Contribuir es una buena forma de presentarte +y conocer a algunos de los miembros de nuestra comunidad. + +1. Si no tienes una cuenta de [GitHub][github], puedes [enviarnos comentarios por correo electrónico][contacto]. Sin embargo, podremos responder más rápidamente si usa uno de los otros métodos que se describen a continuación. + +2. Si tiene una cuenta de[GitHub][github], o están dispuestos a [crear uno][github-join], pero no sabes cómo usar git, puedes informar problemas o sugerir mejoras al [crear un problema o **issue**][nuevo-problema]. Esto nos permite asignar el elemento a alguien y para responder en una conversación abierta. + +3. Si te sientes cómodo con Git, y te gustaría agregar o cambiar material, puede enviar una solicitud de extracción o **pull request**(PR). Las instrucciones para hacer esto [se incluyen a continuación](# using-github). + +## Donde Contribuir + +1. Si deseas cambiar esta lección, por favor trabaje en , que se puede ver en . + +2. Si deseas cambiar la lección de ejemplo, por favor trabaje en , que documenta el formato de nuestras lecciones y se puede ver en . + +3. Si deseas cambiar la plantilla utilizada para los sitios web del taller, por favor trabaje en . La página de inicio de ese repositorio explica cómo configurar sitios web de talleres, mientras que las páginas adicionales en proporcionar más antecedentes sobre nuestras elecciones de diseño. + +4. Si deseas cambiar los archivos de estilo CSS, herramientas, o texto estándar HTML para lecciones o talleres almacenados en `_includes` o` _layouts`, por favor trabaje en . + +## Qué aportar + +Hay muchas maneras de contribuir, de escribir nuevos ejercicios y +mejorar los existentes para actualizar o completar la documentación y +enviando [informes de error o **issues**][nuevo-problema] sobre cosas que no +funcionan, no son claras o faltan. Si estás buscando ideas, por favor +ve [la lista de problemas para este repositorio][issues], o los +problemas para [Data Carpentry][dc-issues] y +[Software Carpentry][swc-issues] proyectos. + +Los comentarios sobre problemas y revisiones de solicitudes de +extracción son igualmente bienvenidos: somos más fuertes juntos +que solos, por eso trabajamos en equipo. Los comentarios de principiantes y recién +llegados son particularmente valiosos: es fácil para las personas +que han estado usando estas lecciones por un tiempo, olvidar lo +impenetrable que puede ser parte de este material, por lo que los +ojos frescos son siempre bienvenidos. + +## Qué *No* contribuir + +Nuestras lecciones ya contienen más material de lo que podemos cubrir +en un taller típico, por lo que usualmente *no* buscamos más +conceptos o herramientas para agregar. Como una regla, si quieres +presentar una nueva idea, debes (a) estimar cuánto tiempo llevará +enseñar y (b) explicar lo que sacaría para darle espacio al nuevo concepto. El primero +alienta a los contribuyentes a ser honestos acerca de los requisitos; +el segundo, pensar mucho sobre las prioridades. + +Tampoco buscamos ejercicios u otro material que sólo se ejecute en +una plataforma. Nuestros talleres suelen contener una mezcla de +usuarios de Windows, Mac OS X y Linux; para ser utilizable, nuestras +lecciones deben correr igualmente bien en las tres plataformas. + +## Usando GitHub + +Si eliges contribuir a través de GitHub, es posible que desees mirar +[Cómo contribuir a un proyecto de código abierto en GitHub][cómo-contribuir]. + +En breve: + +1. La copia publicada de la lección está en la rama `gh-pages` del repositorio (para que GitHub lo regenere automáticamente). Por favor crea todas las ramas de eso, y fusiona la rama `gh-pages` de [repositorio maestro][repo] en la rama` gh-pages` antes de comenzar a trabajar. Por favor, *no* trabaje directamente en su rama `gh-pages`, ya que eso le dificultará trabajar en otras contribuciones. + +2. Usamos [GitHub flow] [github-flow] para gestionar los cambios: +    1. Cree una nueva rama en su copia de escritorio de este repositorio para cada cambio significativo. +    2. Cometer el cambio en esa rama. +    3. Empuje esa rama a su tenedor de este repositorio en GitHub. +    4. Envíe una solicitud de extracción desde esa rama al [repositorio principal] [repo]. +    5. Si recibe comentarios, +        hacer cambios en su escritorio y enviar a su sucursal en GitHub: +        la solicitud de extracción se actualizará automáticamente. + +Cada lección tiene dos mantenedores que revisan problemas y solicitan +extracción o alentar a otros a hacerlo. Los mantenedores son +voluntarios de la comunidad, y tener una opinión final sobre lo que +se fusiona en la lección. + +## Otros recursos + +Discusión general de [Software Carpentry][swc-site] y +[Data Carpentry][dc-site] sucede en la +[lista de distribución de discusiones][lista de discusión], +a la cual todos son bienvenidos. También puedes +[contactarnos por correo electrónico][contacto]. + +[contacto]: mailto:admin@software-carpentry.org [dc-issues]: https://github.com/issues?q=user%3Adatacarpentry [dc-lessons]: http://datacarpentry.org/lessons/ [dc-site]: http://datacarpentry.org/ @@ -143,8 +111,8 @@ You can also [reach us by email][contact]. [github]: http://github.com [github-flow]: https://guides.github.com/introduction/flow/ [github-join]: https://github.com/join -[how-contribute]: https://egghead.io/series/how-to-contribute-to-an-open-source-project-on-github -[new-issue]: https://github.com/swcarpentry/git-novice/issues/new +[cómo-contribuir]: https://egghead.io/series/how-to-contribute-to-an-open-source-project-on-github +[nuevo-problema]: https://github.com/swcarpentry/git-novice/issues/new [issues]: https://github.com/swcarpentry/git-novice/issues/ [repo]: https://github.com/swcarpentry/git-novice/ [swc-issues]: https://github.com/issues?q=user%3Aswcarpentry diff --git a/LICENSE.md b/LICENSE.md index 179758a7e9..4965c27fa1 100644 --- a/LICENSE.md +++ b/LICENSE.md @@ -1,83 +1,83 @@ --- layout: page -title: "Licenses" -permalink: /license/ +title: "Licencias" +root: . --- -## Instructional Material +### Material didáctico -All Software Carpentry and Data Carpentry instructional material is -made available under the [Creative Commons Attribution -license][cc-by-human]. The following is a human-readable summary of -(and not a substitute for) the [full legal text of the CC BY 4.0 -license][cc-by-legal]. +Todo el material instructivo de Software Carpentry and Data Carpentry es +disponible bajo el [Creative Commons Attribution +licencia][cc-por-humano]. El siguiente es un resumen de lectura humana +(y no un sustituto) del [texto legal completo de CC BY 4.0 +licencia][cc-por-legal]. -You are free: +Estas libre: -* to **Share**---copy and redistribute the material in any medium or format -* to **Adapt**---remix, transform, and build upon the material +* **Compartir** --- copiar y redistribuir el material en cualquier medio o formato +* **Adaptar** --- remezclar, transformar y construir sobre el material -for any purpose, even commercially. +para cualquier propósito, incluso comercialmente. -The licensor cannot revoke these freedoms as long as you follow the -license terms. +El licenciante no puede revocar estas libertades mientras siga el +condiciones de la licencia. -Under the following terms: +Bajo los siguientes términos: -* **Attribution**---You must give appropriate credit (mentioning that - your work is derived from work that is Copyright © Software - Carpentry and, where practical, linking to - http://software-carpentry.org/), provide a [link to the - license][cc-by-human], and indicate if changes were made. You may do - so in any reasonable manner, but not in any way that suggests the - licensor endorses you or your use. +* **Atribución** --- Debe otorgar el crédito apropiado (mencionando eso +  su trabajo se deriva del trabajo que es Copyright © Software +  Carpentry y, donde sea práctico, enlace a +  http://software-carpentry.org/), proporcione un [enlace al +  licencia][cc-por-humano], e indique si se realizaron cambios. Puedes hacer +  así que de cualquier manera razonable, pero no de ninguna manera que sugiera +  licenciante lo respalda a usted o a su uso. -**No additional restrictions**---You may not apply legal terms or -technological measures that legally restrict others from doing -anything the license permits. With the understanding that: +**Sin restricciones adicionales** --- No puede aplicar términos legales o +medidas tecnológicas que legalmente restringen a otros a hacer +todo lo que la licencia permita. Entendiendo que: -Notices: +Avisos: -* You do not have to comply with the license for elements of the - material in the public domain or where your use is permitted by an - applicable exception or limitation. -* No warranties are given. The license may not give you all of the - permissions necessary for your intended use. For example, other - rights such as publicity, privacy, or moral rights may limit how you - use the material. +* No tiene que cumplir con la licencia para elementos de la +  material en el dominio público o donde su uso está permitido por un +  excepción o limitación aplicable. +* No se dan garantías. La licencia puede no darle todos los +  permisos necesarios para su uso previsto. Por ejemplo, otro +  derechos como la publicidad, la privacidad, o los derechos morales pueden limitar la forma en que +  usa el material. ## Software -Except where otherwise noted, the example programs and other software -provided by Software Carpentry and Data Carpentry are made available under the -[OSI][osi]-approved -[MIT license][mit-license]. +Salvo que se indique lo contrario, los programas de ejemplo y otro software +proporcionado por Software Carpentry y Data Carpentry están disponibles bajo el +[OSI][osi]-aprobado +[Licencia de MIT][mit-license]. -Permission is hereby granted, free of charge, to any person obtaining -a copy of this software and associated documentation files (the -"Software"), to deal in the Software without restriction, including -without limitation the rights to use, copy, modify, merge, publish, -distribute, sublicense, and/or sell copies of the Software, and to -permit persons to whom the Software is furnished to do so, subject to -the following conditions: +Se concede permiso, de forma gratuita, a cualquier persona que obtenga +una copia de este software y los archivos de documentación asociados (el +"Software"), para tratar el Software sin restricciones, incluyendo +sin limitación, los derechos de uso, copia, modificación, fusión, publicación, +distribuir, sublicenciar y / o vender copias del Software, y +Permitir a las personas a quienes se les proporciona el Software que lo hagan, sujeto a +las siguientes condiciones: -The above copyright notice and this permission notice shall be -included in all copies or substantial portions of the Software. +El aviso de copyright anterior y este aviso de permiso serán +incluido en todas las copias o porciones sustanciales del software. -THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, -EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF -MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND -NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE -LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION -OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION -WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. +EL SOFTWARE SE PROPORCIONA "TAL CUAL", SIN GARANTÍA DE NINGÚN TIPO, +EXPRESO O IMPLICADO, INCLUIDAS, ENTRE OTRAS, LAS GARANTÍAS DE +COMERCIABILIDAD, APTITUD PARA UN PROPÓSITO PARTICULAR Y +NO INFRACCIÓN EN NINGÚN CASO SERÁN LOS AUTORES O LOS TITULARES DE LOS DERECHOS DE AUTOR +RESPONSABLE POR CUALQUIER RECLAMO, DAÑOS U OTRA RESPONSABILIDAD, YA SEA EN ACCIÓN +DEL CONTRATO, EXTRACONTRACTUAL O DE OTRO TIPO, DERIVADOS, FUERA DE O EN CONEXIÓN +CON EL SOFTWARE O EL USO U OTROS TRATOS EN EL SOFTWARE. -## Trademark +## Marca registrada -"Software Carpentry" and "Data Carpentry" and their respective logos -are registered trademarks of [NumFOCUS][numfocus]. +"Software Carpentry" y "Data Carpentry" y sus respectivos logos +son marcas registradas de [NumFOCUS][numfocus]. -[cc-by-human]: https://creativecommons.org/licenses/by/4.0/ +[cc-por-humano]: https://creativecommons.org/licenses/by/4.0/ [cc-by-legal]: https://creativecommons.org/licenses/by/4.0/legalcode -[mit-license]: http://opensource.org/licenses/mit-license.html -[numfocus]: http://numfocus.org/ -[osi]: http://opensource.org +[mit-license]: https://opensource.org/licenses/mit-license.html +[numfocus]: https://numfocus.org/ +[osi]: https://opensource.org \ No newline at end of file diff --git a/Makefile b/Makefile index b5dfe2fa45..df31f00cfc 100644 --- a/Makefile +++ b/Makefile @@ -65,9 +65,9 @@ MARKDOWN_SRC = \ index.md \ CONDUCT.md \ setup.md \ - $(wildcard _episodes/*.md) \ + $(sort $(wildcard _episodes/*.md)) \ reference.md \ - $(wildcard _extras/*.md) \ + $(sort $(wildcard _extras/*.md)) \ LICENSE.md # Generated lesson files in the order they appear in the navigation menu. @@ -75,9 +75,9 @@ HTML_DST = \ ${DST}/index.html \ ${DST}/conduct/index.html \ ${DST}/setup/index.html \ - $(patsubst _episodes/%.md,${DST}/%/index.html,$(wildcard _episodes/*.md)) \ + $(patsubst _episodes/%.md,${DST}/%/index.html,$(sort $(wildcard _episodes/*.md))) \ ${DST}/reference/index.html \ - $(patsubst _extras/%.md,${DST}/%/index.html,$(wildcard _extras/*.md)) \ + $(patsubst _extras/%.md,${DST}/%/index.html,$(sort $(wildcard _extras/*.md))) \ ${DST}/license/index.html ## lesson-md : convert Rmarkdown files to markdown @@ -95,10 +95,6 @@ lesson-check : lesson-check-all : @bin/lesson_check.py -s . -p ${PARSER} -l -w -## lesson-figures : re-generate inclusion displaying all figures. -lesson-figures : - @bin/extract_figures.py -p ${PARSER} ${MARKDOWN_SRC} > _includes/all_figures.html - ## unittest : run unit tests on checking tools. unittest : python bin/test_lesson_check.py diff --git a/README.md b/README.md index 6d7af3eec9..043929402d 100644 --- a/README.md +++ b/README.md @@ -1,11 +1,17 @@ git-novice ========== -An introduction to version control for novices using Git. -Please see for a rendered version of this material, -[the lesson template documentation][lesson-example] -for instructions on formatting, building, and submitting material, -or run `make` in this directory for a list of helpful commands. +# +**NOTA** +Este repositorio esta archivado y sólo tiene modo lectura. +Esta lección ahora se encuentra publicada en https://swcarpentry.github.io/git-novice-es/ con su respectivo repositorio +# + +Una introdución para principiantes sobre control de versiones usando Git. +Puedes encontrar la traducción de este material en +y también puedes ver el [modelo de documentación][lesson-example] +para las instrucciones de formato y como mejorar el material, +o también puedes run `make` en este directorio para ver una lista de comandos útiles. Maintainers: diff --git a/_config.yml b/_config.yml index bda10bdd30..38e3cf520e 100644 --- a/_config.yml +++ b/_config.yml @@ -6,7 +6,7 @@ carpentry: "swc" # Overall title for pages. -title: "Version Control with Git" +title: "Control de versiones con Git" # Contact email address. email: lessons@software-carpentry.org diff --git a/_episodes/01-basics.md b/_episodes/01-basics.md index 3a0d791700..6b05d1c45f 100644 --- a/_episodes/01-basics.md +++ b/_episodes/01-basics.md @@ -1,77 +1,70 @@ --- -title: Automated Version Control +title: Control Automatizado de Versiones teaching: 5 exercises: 0 questions: -- "What is version control and why should I use it?" +- "¿Qué es el control de versiones y por qué se deberá usar?" objectives: -- "Understand the benefits of an automated version control system." -- "Understand the basics of how Git works." +- "Comprender los beneficios de usar un sistema automático de control de versiones." +- "Comprender los fundamentos básicos del funcionamiento de Git." keypoints: -- "Version control is like an unlimited 'undo'." -- "Version control also allows many people to work in parallel." +- "El control de versiones es como un 'deshacer' sin límites." +- "El control de versiones permite que mucha gente trabaje en lo mismo en paralelo." --- -We'll start by exploring how version control can be used -to keep track of what one person did and when. -Even if you aren't collaborating with other people, -automated version control is much better than this situation: +Empezaremos por explorar cómo el control de versiones puede ser usado +para hacer un seguimiento de lo que hizo una persona y cuándo. +Incluso si no se está colaborando con otras personas, +el control automatizado de versiones es mucho mejor que la siguiente situación: [![Piled Higher and Deeper by Jorge Cham, http://www.phdcomics.com/comics/archive_print.php?comicid=1531](../fig/phd101212s.png)](http://www.phdcomics.com) -"Piled Higher and Deeper" by Jorge Cham, http://www.phdcomics.com +"La pila mas alta y mas profunda" por Jorge Cham, http://www.phdcomics.com -We've all been in this situation before: it seems ridiculous to have -multiple nearly-identical versions of the same document. Some word -processors let us deal with this a little better, such as Microsoft -Word's [Track Changes](https://support.office.com/en-us/article/Track-changes-in-Word-197ba630-0f5f-4a8e-9a77-3712475e806a), Google Docs' [version -history](https://support.google.com/docs/answer/190843?hl=en), or LibreOffice's [Recording and Displaying Changes](https://help.libreoffice.org/Common/Recording_and_Displaying_Changes). +Todos hemos estado en esta situación alguna vez: parece ridículo tener +varias versiones casi idénticas del mismo documento. Algunos procesadores de texto +nos permiten lidiar con esto un poco mejor, como por ejemplo el [*Track Changes* de Microsoft Word](https://support.office.com/en-us/article/Track-changes-in-Word-197ba630-0f5f-4a8e-9a77-3712475e806a), el [historial de versiones de Google](https://support.google.com/docs/answer/190843?hl=en) o la [grabación y visualización de cambios de LibreOffice](https://help.libreoffice.org/Common/Recording_and_Displaying_Changes). -Version control systems start with a base version of the document and -then save just the changes you made at each step of the way. You can -think of it as a tape: if you rewind the tape and start at the base -document, then you can play back each change and end up with your -latest version. +Los sistemas de control de versiones comienzan con una versión básica del documento y +luego van guardando sólo los cambios que se hicieron en cada paso del proceso. Se puede +pensar en ello como en una cinta: si se rebobina la cinta y se inicia de nuevo en el documento +base, se puede reproducir cada cambio y terminar con la versión más reciente. ![Changes Are Saved Sequentially](../fig/play-changes.svg) -Once you think of changes as separate from the document itself, you -can then think about "playing back" different sets of changes onto the -base document and getting different versions of the document. For -example, two users can make independent sets of changes based on the -same document. +Una vez que piensas en los cambios como separados del documento en sí, entonces se puede pensar en "deshacer" diferentes conjuntos de cambios en el documento base y obtener así diferentes versiones del documento. Por ejemplo, dos usuarios pueden hacer conjuntos independientes de cambios basados en el mismo documento. ![Different Versions Can be Saved](../fig/versions.svg) -Unless there are conflicts, you can even play two sets of changes onto the same base document. +A menos que haya conflictos, se puede incluso tener dos conjuntos de cambios en el mismo documento base. ![Multiple Versions Can be Merged](../fig/merge.svg) -A version control system is a tool that keeps track of these changes for us and -helps us version and merge our files. It allows you to -decide which changes make up the next version, called a -[commit]({{ page.root }}/reference/#commit), and keeps useful metadata about them. The -complete history of commits for a particular project and their metadata make up -a [repository]({{ page.root }}/reference/#repository). Repositories can be kept in sync -across different computers facilitating collaboration among different people. +Un sistema de control de versiones es una herramienta que realiza un seguimiento de estos cambios para nosotros y +nos ayuda a controlar la versión y fusionar nuestros archivos. Nos permite +decidir qué cambios conforman la siguiente versión, a lo que llamamos hacer un +[**commit**]({{ page.root }}/reference/#commit), y mantiene metadatos útiles sobre dichos cambios. El +historial completo de **commits** para un proyecto en particular y sus metadatos forman un +[repositorio]({{ page.root }}/reference/#repository). Los repositorios pueden mantenerse sincronizados +en diferentes computadoras, facilitando así la colaboración entre diferentes personas. -> ## The Long History of Version Control Systems +> ## La larga historia de los sistemas de control de versiones > -> Automated version control systems are nothing new. -> Tools like RCS, CVS, or Subversion have been around since the early 1980s and are used by many large companies. -> However, many of these are now becoming considered as legacy systems due to various limitations in their capabilities. -> In particular, the more modern systems, such as Git and [Mercurial](http://swcarpentry.github.io/hg-novice/) -> are *distributed*, meaning that they do not need a centralized server to host the repository. -> These modern systems also include powerful merging tools that make it possible for multiple authors to work within -> the same files concurrently. -{: .callout} - +> Los sistemas automatizados de control de versiones no son nada nuevo. +> Herramientas como RCS, CVS o Subversion han existido desde principios de los 1980 y son utilizadas por muchas grandes empresas. +> Sin embargo, muchos de estos han sido relegados debido a lo limitado de su capacidad. +> En particular, los sistemas más modernos, como Git y [Mercurial](http://swcarpentry.github.io/hg-novice/) +> son *distribuidos*, lo que significa que no necesitan un servidor centralizado para alojar el repositorio. +> Estos sistemas modernos también incluyen potentes herramientas de fusión que hacen posible que múltiples autores trabajen dentro de +> los mismos archivos simultáneamente. +{:.callout} + > ## Paper Writing > -> * Imagine you drafted an excellent paragraph for a paper you are writing, but later ruin it. How would you retrieve -> the *excellent* version of your conclusion? Is it even possible? +> Imagina que has redactado un excelente párrafo para un artículo que estás escribiendo, pero más tarde lo estropeas. ¿Cómo recuperarías +> aquella *excelente* versión de la conclusión? ¿Es esto posible? > -> * Imagine you have 5 co-authors. How would you manage the changes and comments they make to your paper? -> If you use LibreOffice Writer or Microsoft Word, what happens if you accept changes made using the -> `Track Changes` option? Do you have a history of those changes? +> Imagina que tienes 5 coautores. ¿Cómo administrarías los cambios y comentarios que ellos hagan en el artículo? +> Si usas LibreOffice Writer o Microsoft Word, ¿qué sucede si aceptas los cambios realizados con la opción +> ` Track Changes`? ¿Tienes un historial de esos cambios? {: .challenge} diff --git a/_episodes/02-setup.md b/_episodes/02-setup.md index 224c5e9798..1babe5c0a6 100644 --- a/_episodes/02-setup.md +++ b/_episodes/02-setup.md @@ -1,28 +1,28 @@ --- -title: Setting Up Git +title: Configurando Git teaching: 5 exercises: 0 questions: -- "How do I get set up to use Git?" +- "Cómo me preparo para utilizar Git?" objectives: -- "Configure `git` the first time it is used on a computer." -- "Understand the meaning of the `--global` configuration flag." +- "Configurar `git` la primera vez que utilice la computadora." +- "Comprender el significado de la bandera de configuración `--global`." keypoints: -- "Use `git config` to configure a user name, email address, editor, and other preferences once per machine." +- "Use `git config` para configurar un nombre de usuario, email, editor, y otras preferencias." --- -When we use Git on a new computer for the first time, -we need to configure a few things. Below are a few examples -of configurations we will set as we get started with Git: +Cuando usamos Git en una computadora por primera vez, +es necesario configurar algunas cosas. A continuación se presentan algunos ejemplos +de configuraciones que estableceremos a medida que trabajemos con Git: -* our name and email address, -* to colorize our output, -* what our preferred text editor is, -* and that we want to use these settings globally (i.e. for every project) +* nombre y correo electrónico, +* color de nuestra salida, +* cual es nuestro editor de texto preferido, +* y que queremos utilizar éstos ajustes globalmente (es decir, para cada proyecto) -On a command line, Git commands are written as `git verb`, -where `verb` is what we actually want to do. So here is how -Dracula sets up his new laptop: +En línea de comandos, los comandos de Git se escriben como `git verb`, +donde` verb` es lo que queremos hacer. Así es como +Drácula configura su computadora: ~~~ $ git config --global user.name "Vlad Dracula" @@ -31,60 +31,58 @@ $ git config --global color.ui "auto" ~~~ {: .bash} -Please use your own name and email address instead of Dracula's. This user name and email will be associated with your subsequent Git activity, -which means that any changes pushed to -[GitHub](http://github.com/), -[BitBucket](http://bitbucket.org/), -[GitLab](http://gitlab.com/) or -another Git host server -in a later lesson will include this information. +Utiliza tu propio nombre y dirección de correo electrónico en lugar del de Drácula. El nombre de usuario y el correo electrónico se asociarán con tu actividad posterior de Git, +lo que significa que cualquier cambio realizado en +[GitHub] (http://github.com/), +[BitBucket] (http://bitbucket.org/), +[ GitLab] (http://gitlab.com/) u +otro servidor de Git +en una lección posterior incluirá esta información. -For these lessons, we will be interacting with [GitHub](http://github.com/) and so the email address used should be the same as the one used when setting up your GitHub account. If you are concerned about privacy, please review [GitHub's instructions for keeping your email address private][git-privacy]. -If you elect to use a private email address with GitHub, then use that same email address for the `user.email` value, e.g. `username@users.noreply.github.com` replacing `username` with your GitHub one. You can change the email address later on by using the `git config` command again. +Para estas lecciones, estaremos interactuando con [GitHub] (http://github.com/), por lo tanto la dirección de correo electrónico utilizada debe ser la misma que utilizaste al configurar tu cuenta de GitHub. Si te preocupa la privacidad, revisa [las instrucciones de GitHub para mantener tu dirección de correo electrónico privada] [git-privacy]. +Si eliges utilizar una dirección de correo electrónico privada con GitHub, usa la misma dirección de correo electrónico para el valor `user.email`, por ejemplo, `username@users.noreply.github.com` reemplazando` username` con tu nombre de usuario de GitHub. Puedes cambiar la dirección de correo electrónico posteriormente utilizando el comando `git config` nuevamente. -Dracula also has to set his favorite text editor, following this table: +Drácula también tiene que establecer su editor de texto favorito, siguiendo esta tabla: -| Editor | Configuration command | +| Editor | Comando de configuración | |:-------------------|:-------------------------------------------------| | Atom | `$ git config --global core.editor "atom --wait"`| | nano | `$ git config --global core.editor "nano -w"` | -| Text Wrangler (Mac) | `$ git config --global core.editor "edit -w"` | +| TextWrangler (Mac) | `$ git config --global core.editor "edit -w"` | | Sublime Text (Mac) | `$ git config --global core.editor "subl -n -w"` | -| Sublime Text (Win, 32-bit install) | `$ git config --global core.editor "'c:/program files (x86)/sublime text 3/sublime_text.exe' -w"` | -| Sublime Text (Win, 64-bit install) | `$ git config --global core.editor "'c:/program files/sublime text 3/sublime_text.exe' -w"` | -| Notepad++ (Win, 32-bit install) | `$ git config --global core.editor "'c:/program files (x86)/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noPlugin"`| -| Notepad++ (Win, 64-bit install) | `$ git config --global core.editor "'c:/program files/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noPlugin"`| +| Sublime Text (Win, 32-bit) | `$ git config --global core.editor "'c:/program files (x86)/sublime text 3/sublime_text.exe' -w"` | +| Sublime Text (Win, 64-bit) | `$ git config --global core.editor "'c:/program files/sublime text 3/sublime_text.exe' -w"` | +| Notepad++ (Win, 32-bitl) | `$ git config --global core.editor "'c:/program files (x86)/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noPlugin"`| +| Notepad++ (Win, 64-bit) | `$ git config --global core.editor "'c:/program files/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noPlugin"`| | Kate (Linux) | `$ git config --global core.editor "kate"` | | Gedit (Linux) | `$ git config --global core.editor "gedit --wait --new-window"` | | Scratch (Linux) | `$ git config --global core.editor "scratch-text-editor"` | | emacs | `$ git config --global core.editor "emacs"` | | vim | `$ git config --global core.editor "vim"` | -It is possible to reconfigure the text editor for Git whenever you want to change it. +Es posible reconfigurar el editor de texto para Git siempre que quieras. -> ## Exiting Vim +> ## Saliendo de Vim > -> Note that `vim` is the default editor for for many programs, if you haven't used `vim` before and wish to exit a session, type `Esc` then `:q!` and `Enter`. +>Ten en cuenta que `vim` es el editor por defecto para muchos programas, si no has utilizado` vim` antes y deseas salir de una sesión, presiona la tecla `Esc` y posteriormente escribe `: q!` y `Enter`. {: .callout} -The four commands we just ran above only need to be run once: the flag `--global` tells Git -to use the settings for every project, in your user account, on this computer. +Los cuatro comandos que acabamos de ejecutar sólo se tienen que ejecutar una vez: la opción `--global` le dice a Git que use la configuración para cada proyecto, en tu cuenta de usuario, en esta computadora. -You can check your settings at any time: +Puedes comprobar tu configuración en cualquier momento: ~~~ $ git config --list ~~~ {: .bash} -You can change your configuration as many times as you want: just use the -same commands to choose another editor or update your email address. +Puedes cambiar la configuración tantas veces como quieras: sólo usa los mismos comandos para elegir otro editor o actualizar tu correo electrónico. > ## Proxy > -> In some networks you need to use a -> [proxy](https://en.wikipedia.org/wiki/Proxy_server). If this is the case, you -> may also need to tell Git about the proxy: +> En algunas redes es necesario usar un +> [proxy](https://en.wikipedia.org/wiki/Proxy_server). Si este es el caso, es +> posible que también necesites proporcionarle a Git el proxy: > > ~~~ > $ git config --global http.proxy proxy-url @@ -92,7 +90,7 @@ same commands to choose another editor or update your email address. > ~~~ > {: .bash} > -> To disable the proxy, use +> Para deshabilitar el proxy, utiliza > > ~~~ > $ git config --global --unset http.proxy @@ -101,9 +99,9 @@ same commands to choose another editor or update your email address. > {: .bash} {: .callout} -> ## Git Help and Manual +> ## Ayuda y manual de Git > -> Always remember that if you forget a `git` command, you can access the list of commands by using `-h` and access the Git manual by using `--help` : +> Ten presente que si no recuerdas algún comando de `git`, puedes acceder a la lista de comando utilizando la opción `-h` y al manual de Git con la opción `--help` : > > ~~~ > $ git config -h diff --git a/_episodes/03-create.md b/_episodes/03-create.md index a425c34028..bb88865a65 100644 --- a/_episodes/03-create.md +++ b/_episodes/03-create.md @@ -1,18 +1,18 @@ --- -title: Creating a Repository +title: Creando un repositorio teaching: 10 exercises: 0 questions: -- "Where does Git store information?" +- "¿Dónde almacena Git la información?" objectives: -- "Create a local Git repository." +- "Crear un repositorio local de Git." keypoints: -- "`git init` initializes a repository." +- "`git init` inicializa un repositorio." --- -Once Git is configured, -we can start using it. -Let's create a directory for our work and then move into that directory: +Una vez que Git está configurado, +podemos comenzar a usarlo. +Vamos a crear un directorio para nuestro trabajo y nos movemos dentro de ese directorio: ~~~ $ mkdir planets @@ -20,24 +20,24 @@ $ cd planets ~~~ {: .bash} -Then we tell Git to make `planets` a [repository]({{ page.root }}/reference/#repository)—a place where -Git can store versions of our files: +Después le indicamos a Git hacer de `planets` un [repository]({{ page.root }}/reference/#repository)—lugar donde +Git puede almacenar las versiones de nuestros archivos: ~~~ $ git init ~~~ {: .bash} -If we use `ls` to show the directory's contents, -it appears that nothing has changed: +Si usamos `ls` para mostrar el contenido del directorio, +parece que nada ha cambiado: ~~~ $ ls ~~~ {: .bash} -But if we add the `-a` flag to show everything, -we can see that Git has created a hidden directory within `planets` called `.git`: +Pero si agregamos la opción `-a` para mostrar todo, +podemos ver que Git ha creado un directorio oculto dentro de `planets` llamado `.git`: ~~~ $ ls -a @@ -49,12 +49,12 @@ $ ls -a ~~~ {: .output} -Git stores information about the project in this special sub-directory. -If we ever delete it, -we will lose the project's history. +Git almacena información sobre el proyecto en este subdirectorio especial. +Si alguna vez lo borramos, +perderemos la historia del proyecto. -We can check that everything is set up correctly -by asking Git to tell us the status of our project: +Podemos revisar que todo está configurado correctamente +pidiendo a Git que nos informe el estado de nuestro proyecto: ~~~ $ git status @@ -70,35 +70,35 @@ nothing to commit (create/copy files and use "git add" to track) ~~~ {: .output} -> ## Places to Create Git Repositories +> ## Lugares para crear repositorio Git > -> Dracula starts a new project, `moons`, related to his `planets` project. -> Despite Wolfman's concerns, he enters the following sequence of commands to -> create one Git repository inside another: +> Dracula comienza un nuevo proyecto, `moons`, relacionado a su proyecto `planets`. +> A pesar de las preocupaciones de Wolfman, él ingresa la siguiente secuencia de comandos +> para crear un repositorio Git dentro de otro: > > ~~~ -> $ cd # return to home directory -> $ mkdir planets # make a new directory planets -> $ cd planets # go into planets -> $ git init # make the planets directory a Git repository -> $ mkdir moons # make a sub-directory planets/moons -> $ cd moons # go into planets/moons -> $ git init # make the moons sub-directory a Git repository +> $ cd # volver al directorio de inicio +> $ mkdir planets # crear un nuevo diretorio llamado planets +> $ cd planets # entrar al directorio planets +> $ git init # hacer del directorio planets directory un repositorio Git +> $ mkdir moons # crear un subdirectorio planets/moons +> $ cd moons # entrar al directorio planets/moons +> $ git init # hacer del subdirectorio moons un repositorio Git > ~~~ > {: .bash} > -> Why is it a bad idea to do this? (Notice here that the `planets` project is now also tracking the entire `moons` repository.) -> How can Dracula undo his last `git init`? +> ¿Por qué es una mala idea hacer esto? (Observa aquí que el proyecto `planets` ahora también se encuentra controlando el repositorio completo de `moons`.) +> ¿Cómo puede Dracula deshacer su último `git init`? > -> > ## Solution +> > ## Solución > > -> > Git repositories can interfere with each other if they are "nested" in the -> > directory of another: the outer repository will try to version-control -> > the inner repository. Therefore, it's best to create each new Git -> > repository in a separate directory. To be sure that there is no conflicting -> > repository in the directory, check the output of `git status`. If it looks -> > like the following, you are good to go to create a new repository as shown -> > above: +> > Los repositorios Git pueden interferir entre sí si están "anidados" dentro de +> > otro directorio: el repositorio exterior intentará controlar la versión +> > del repositorio interno. Por lo tanto, lo mejor es crear cada nuevo repositorio Git +> > en un directorio separado. Para asegurarte que no hay un repositorio en conflicto +> > en el directorio, revisa la salida de `git status`. Si se parece a +> > lo siguiente, podrás crear un nuevo repositorio como se ha mostrado +> > arriba: > > > > ~~~ > > $ git status @@ -109,23 +109,23 @@ nothing to commit (create/copy files and use "git add" to track) > > ~~~ > > {: .output} > > -> > Note that we can track files in directories within a Git: +> > Ten en cuenta que podemos rastrear archivos en directorios dentro de Git: > > > > ~~~ -> > $ touch moon phobos deimos titan # create moon files -> > $ cd .. # return to planets directory -> > $ ls moons # list contents of the moons directory -> > $ git add moons/* # add all contents of planets/moons -> > $ git status # show moons files in staging area -> > $ git commit -m "add moon files" # commit planets/moons to planets Git repository +> > $ touch moon phobos deimos titan # crear archivos moon +> > $ cd .. # regresar al directorio planets +> > $ ls moons # listar el contenido del directorio moons +> > $ git add moons/* # añadir todo el contenido de planets/moons +> > $ git status # mostrar los archivos moons en el área de almacenamiento +> > $ git commit -m "add moon files" # ingresar planets/moons al repositorio Git planets > > ~~~ > > {: .bash} > > -> > Similarly, we can ignore (as discussed later) entire directories, such as the `moons` directory: +> > De manera similar, podemos ignorar (como comentamos anteriormente) directorios completos, como el directorio `moons`: > > > > ~~~ -> > $ nano .gitignore # open the .gitignore file in the texteditor to add the moons directory -> > $ cat .gitignore # if you run cat afterwards, it should look like this: +> > $ nano .gitignore # abrir el archivo .gitignore en un editor para agregar el directorio moons +> > $ cat .gitignore # si después se ejecuta el comando cat, debería verse así: > > ~~~ > > {: .bash} > > @@ -134,16 +134,16 @@ nothing to commit (create/copy files and use "git add" to track) > > ~~~ > > {: .output} > > -> > To recover from this little mistake, Dracula can just remove the `.git` -> > folder in the moons subdirectory. To do so he can run the following command from inside the 'moons' directory: +> > Para recuperarse de este pequeño error, Dracula puede simplemente eliminar el directorio `.git` +> > del subdirectorio moons. Para ello puede ejecutar el siguiente comando desde el interior del directorio 'moons': > > > > ~~~ > > $ rm -rf moons/.git > > ~~~ > > {: .bash} > > -> > But be careful! Running this command in the wrong directory, will remove -> > the entire git-history of a project you might wanted to keep. Therefore, always check your current directory using the +> > !Pero ten cuidado! Ejecutar este comando en el directorio incorrecto, eliminará +> > toda la historia git de un proyecto que tú habrías querido conservar. Por lo tanto, revisa siempre tu directorio actual usando el comando > > command `pwd`. > {: .solution} {: .challenge} diff --git a/_episodes/04-changes.md b/_episodes/04-changes.md index 9663456ec1..06e6c200b6 100644 --- a/_episodes/04-changes.md +++ b/_episodes/04-changes.md @@ -1,57 +1,57 @@ --- -title: Tracking Changes +title: Rastreando Cambios teaching: 20 exercises: 0 questions: -- "How do I record changes in Git?" -- "How do I check the status of my version control repository?" -- "How do I record notes about what changes I made and why?" +- "¿Cómo registro cambios en Git?" +- "¿Cómo reviso el estatus de mi repositorio de control de versiones?" +- "¿Cómo registro notas acerca de los cambios que he hecho y por qué?" objectives: -- "Go through the modify-add-commit cycle for one or more files." -- "Explain where information is stored at each stage of Git commit workflow." -- "Distinguish between descriptive and non-descriptive commit messages." +- "Ir a traves del ciclo modificar-agregar-commit para uno o más archivos." +- "Explicar donde se almacena la información en cada etapa del flujo de trabajo de un **commit** de Git." +- "Distinguir entre mensajes descriptivos y no-descriptivos de un **commit**." keypoints: -- "`git status` shows the status of a repository." -- "Files can be stored in a project's working directory (which users see), the staging area (where the next commit is being built up) and the local repository (where commits are permanently recorded)." -- "`git add` puts files in the staging area." -- "`git commit` saves the staged content as a new commit in the local repository." -- "Always write a log message when committing changes." +- "`git status` muestra el estatus de un repositorio." +- "Los archivos pueden ser almacenados en un directorio de trabajo del proyecto (el cual ven los usuarios), el área de ensayo (donde el siguiente **commit** está siendo construido) y el repositorio local (donde los **commits** son registrados permanentemente)." +- "`git add` pone archivos en el área de ensayo." +- "`git commit` guarda el contenido del **staging area** como un nuevo **commit** en el repositorio local." +- "Siempre escribe un mensaje de registro cuando hagas un **commit** con cambios." --- -First let's make sure we're still in the right directory. -You should be in the `planets` directory. +Primero asegúrate que estamos aún en el directorio correcto. +Tú deberías estar en el directorio `planets`. ~~~ $ pwd ~~~ {: .bash} -If you are still in `moons` navigate back up to `planets` +Si aún estás en `moons` navega de regreso a `planets` ~~~ $ cd .. ~~~ {: .bash} -Let's create a file called `mars.txt` that contains some notes -about the Red Planet's suitability as a base. -We'll use `nano` to edit the file; -you can use whatever editor you like. -In particular, this does not have to be the `core.editor` you set globally earlier. But remember, the bash command to create or edit a new file will depend on the editor you choose (it might not be `nano`). For a refresher on text editors, check out ["Which Editor?"](https://swcarpentry.github.io/shell-novice/03-create/) in [The Unix Shell](https://swcarpentry.github.io/shell-novice/) lesson. +Vamos a crear un archivo llamado `mars.txt` que contiene algunas notas +sobre Red Planet's suitability como base. +Usaremos `nano`para editar el archivo; +puedes usar el editor que prefieras. +En particular, éste no tiene que ser el `core.editor` que definiste globalmente con anterioridad. Pero recuerda, los comandos **bash** para crear o editar un nuevo archivo van a depender del editor que tú escojas (podría no ser `nano`). Para una actualización sobre editores de texto, echa un vistazo ["¿Cuál editor?"](https://swcarpentry.github.io/shell-novice/03-create/) en la lección [El Shell Unix](https://swcarpentry.github.io/shell-novice/) . ~~~ $ nano mars.txt ~~~ {: .bash} -Type the text below into the `mars.txt` file: +Teclea el texto siguiente en el archivo `mars.txt`: ~~~ Cold and dry, but everything is my favorite color ~~~ {: .output} -`mars.txt` now contains a single line, which we can see by running: +`mars.txt` ahora contiene una sola línea, la cual podemos ver ejecutando: ~~~ $ ls @@ -73,8 +73,8 @@ Cold and dry, but everything is my favorite color ~~~ {: .output} -If we check the status of our project again, -Git tells us that it's noticed the new file: +Si revisamos el estatus de nuestro proyecto otra vez, +Git nos dice que ha notado el nuevo archivo: ~~~ $ git status @@ -94,16 +94,15 @@ nothing added to commit but untracked files present (use "git add" to track) ~~~ {: .output} -The "untracked files" message means that there's a file in the directory -that Git isn't keeping track of. -We can tell Git to track a file using `git add`: +El mensaje de "untracked files" significa que hay un archivo en el directorio +que Git no le está siguiendo la pista. Podemos decirle a Git que le siga la pista a un archivo usando `git add`: ~~~ $ git add mars.txt ~~~ {: .bash} -and then check that the right thing happened: +y luego verifica que pasó lo correcto: ~~~ $ git status @@ -123,10 +122,10 @@ Changes to be committed: ~~~ {: .output} -Git now knows that it's supposed to keep track of `mars.txt`, -but it hasn't recorded these changes as a commit yet. -To get it to do that, -we need to run one more command: +Git ahora sabe que tiene que seguir la pista de `mars.tx`, +pero no ha registrado estos cambios con un **commit** aún. +Para que lo haga, +necesitamos ejecutar un comando más: ~~~ $ git commit -m "Start notes on Mars as a base" @@ -140,24 +139,24 @@ $ git commit -m "Start notes on Mars as a base" ~~~ {: .output} -When we run `git commit`, -Git takes everything we have told it to save by using `git add` -and stores a copy permanently inside the special `.git` directory. -This permanent copy is called a [commit]({{ page.root }}/reference/#commit) -(or [revision]({{ page.root }}/reference/#revision)) and its short identifier is `f22b25e` -(Your commit may have another identifier.) +Cuando ejecutamos `git commit`, +Git toma todo lo que le hemos dicho para salvarlo usando `git add` +y almacena una copia permanentemente dentro del directorio especial `.git`. +Esta copia permanente es llamada un [commit]({{ page.root }}/reference/#commit) +(or [revision]({{ page.root }}/reference/#revision)) y su identificador corto es `f22b25e` +(Tu **commit** podría tener otro identificador.) -We use the `-m` flag (for "message") -to record a short, descriptive, and specific comment that will help us remember later on what we did and why. -If we just run `git commit` without the `-m` option, -Git will launch `nano` (or whatever other editor we configured as `core.editor`) -so that we can write a longer message. +Usamos la bandera `-m` (de "message") +para registrar un comentario corto, descriptivo y específico que nos ayudará a recordar más tarde lo que hicimos y por qué. +Si ejecutamos `git commit` sin la opción `-m`, +Git ejecutará `nano` (o cualquier otro editor que configuramos como `core.editor`) +así que podemos escribir un mensaje más largo. -[Good commit messages][commit-messages] start with a brief (<50 characters) summary of -changes made in the commit. If you want to go into more detail, add -a blank line between the summary line and your additional notes. +[Los Buenos mensajes en un **commit**][commit-messages] inician con un breve resumen (<50 caracteres) de los +cambios hechos en el **commit**. Si quieres entrar en más detalles, agrega +una línea blanca entre la línea del resumen y tus notas adicionales. -If we run `git status` now: +Si ejecutamos `git status` ahora: ~~~ $ git status @@ -170,9 +169,9 @@ nothing to commit, working directory clean ~~~ {: .output} -it tells us everything is up to date. -If we want to know what we've done recently, -we can ask Git to show us the project's history using `git log`: +nos dice que todo está actualizado. +Si queremos saber lo que hemos hecho recientemente, +podemos pedir a Git que nos muestre la historia del proyecto usando `git log`: ~~~ $ git log @@ -188,27 +187,27 @@ Date: Thu Aug 22 09:51:46 2013 -0400 ~~~ {: .output} -`git log` lists all commits made to a repository in reverse chronological order. -The listing for each commit includes -the commit's full identifier -(which starts with the same characters as -the short identifier printed by the `git commit` command earlier), -the commit's author, -when it was created, -and the log message Git was given when the commit was created. - -> ## Where Are My Changes? -> -> If we run `ls` at this point, we will still see just one file called `mars.txt`. -> That's because Git saves information about files' history -> in the special `.git` directory mentioned earlier -> so that our filesystem doesn't become cluttered -> (and so that we can't accidentally edit or delete an old version). +`git log` lista todos los **commits** hechos a un repositorio en orden cronológico inverso. +El listado de cada **commit** incluye +el identificador completo del **commit** +(el cual inicia con el mismo caracter que +el identificador corto que imprime el comando `git commit` anteriormente ), +el autor del **commit**, +cuándo fue creado, +y el mensaje de registro que se le dio a Git cuando el **commit** fue creado. + +> ## ¿Dónde están mis cambios? +> +> Si ejecutamos `ls` en este punto, aún veremos un solo archivo llamado `mars.txt`. +> Esto es porque Git guarda información acerca de la historia de los archivos +> en el directorio especial `.git` mencionado antes +>para que nuestro sistema de archivos no se abarrote +> (y para que no podamos editar o borrar accidentalmente una versión anterior). {: .callout} -Now suppose Dracula adds more information to the file. -(Again, we'll edit with `nano` and then `cat` the file to show its contents; -you may use a different editor, and don't need to `cat`.) +Ahora supón que Dracula agrega más información al archivo. +(Otra vez, editaremos con `nano` y luego con `cat` mostraremos el contenido del archivo; +podrías usar un editor diferente y no necesitar a `cat`.) ~~~ $ nano mars.txt @@ -222,8 +221,8 @@ The two moons may be a problem for Wolfman ~~~ {: .output} -When we run `git status` now, -it tells us that a file it already knows about has been modified: +Cuando ejecutamos `git status` ahora +nos dice que un archivo ya sabe que ha sido modificado: ~~~ $ git status @@ -242,16 +241,16 @@ no changes added to commit (use "git add" and/or "git commit -a") ~~~ {: .output} -The last line is the key phrase: +La última línea es la frase clave: "no changes added to commit". -We have changed this file, -but we haven't told Git we will want to save those changes -(which we do with `git add`) -nor have we saved them (which we do with `git commit`). -So let's do that now. It is good practice to always review -our changes before saving them. We do this using `git diff`. -This shows us the differences between the current state -of the file and the most recently saved version: +Hemos cambiado este archivo, +pero no le hemos dicho a Git que queremos que guarde los cambios +(lo cual hacemos con `git add`) +ni lo hemos guardado (lo cual hacemos con `git commit`). +Así que hagamos eso ahora. Es una buena práctica revisar siempre +nuestros cambios antes de guardarlos. Hacemos esto usando `git diff`. +Esto nos muestra las diferencias entre el estado actual +del archivo y la versión guardada más reciente: ~~~ $ git diff @@ -269,23 +268,23 @@ index df0654a..315bf3a 100644 ~~~ {: .output} -The output is cryptic because -it is actually a series of commands for tools like editors and `patch` -telling them how to reconstruct one file given the other. -If we break it down into pieces: +La salida es críptica porque +actualmente es una serie de comandos para herramientas como editores y `patch` +que les dicen cómo reconstruir un archivo dado el otro. +Si lo dividimos en pedazos: -1. The first line tells us that Git is producing output similar to the Unix `diff` command - comparing the old and new versions of the file. -2. The second line tells exactly which versions of the file - Git is comparing; - `df0654a` and `315bf3a` are unique computer-generated labels for those versions. -3. The third and fourth lines once again show the name of the file being changed. -4. The remaining lines are the most interesting, they show us the actual differences - and the lines on which they occur. - In particular, - the `+` marker in the first column shows where we added a line. +1. La primera línea nos dice que Git está produciendo una salida similar a la del comando Unix `diff` + comparando las versiones anterior y nueva del archivo. +2. La segunda línea dice exactamente cuáles versiones del archivo + está comparando Git; + `df0654a` y `315bf3a` son etiquetas únicas generadas por computadora para esas versiones. +3. Las líneas tercera y cuarta muestran una vez más el nombre del archivo que se está cambiando. +4. Las líneas restantes son las más interesantes, ellas nos muestran las diferencias actuales + y las líneas donde ellas ocurren. + En particular, + el marcador `+` en la primera columna muestra dónde agregamos una línea. -After reviewing our change, it's time to commit it: +Después de revisar nuestro cambio, es tiempo de hacer un **commit** de eso: ~~~ $ git commit -m "Add concerns about effects of Mars' moons on Wolfman" @@ -305,9 +304,9 @@ no changes added to commit (use "git add" and/or "git commit -a") ~~~ {: .output} -Whoops: -Git won't commit because we didn't use `git add` first. -Let's fix that: +Vaya: +Git no hará **commit** porque no usamos `git add` primero. +Arreglemos esto: ~~~ $ git add mars.txt @@ -321,51 +320,52 @@ $ git commit -m "Add concerns about effects of Mars' moons on Wolfman" ~~~ {: .output} -Git insists that we add files to the set we want to commit -before actually committing anything. This allows us to commit our -changes in stages and capture changes in logical portions rather than -only large batches. -For example, -suppose we're adding a few citations to our supervisor's work -to our thesis. -We might want to commit those additions, -and the corresponding addition to the bibliography, -but *not* commit the work we're doing on the conclusion -(which we haven't finished yet). - -To allow for this, -Git has a special *staging area* -where it keeps track of things that have been added to -the current [changeset]({{ page.root }}/reference/#changeset) -but not yet committed. +Git insiste en que agreguemos archivos al conjunto que queremos hacer **commit** +antes de hacer **commit** real de alguna cosa. Esto permite hacer **commit** de nuestros +cambios en etapas y atrapar cambios en porciones lógicas en lugar de +solo lotes grandes. +Por ejemplo, +supongamos que agregamos pocas citas para nuestro supervisor de trabajo +en nuestra tesis. +Podríamos querer hacer **commit** a esas adiciones, +y su correspondiente adición a la bibliografía, +pero *no* hacer **commit** del trabajo que estamos haciendo en la conclusión +(el cual no hemos terminado aún). + + +Para permitir esto, +Git tiene un *staging area* especial +donde mantiene registro de cosas que han sido agregadas a +el actual [changeset]({{ page.root }}/reference/#changeset) +pero aún no se hace **commit**. > ## Staging Area > -> If you think of Git as taking snapshots of changes over the life of a project, -> `git add` specifies *what* will go in a snapshot -> (putting things in the staging area), -> and `git commit` then *actually takes* the snapshot, and -> makes a permanent record of it (as a commit). -> If you don't have anything staged when you type `git commit`, -> Git will prompt you to use `git commit -a` or `git commit --all`, -> which is kind of like gathering *everyone* for the picture! -> However, it's almost always better to -> explicitly add things to the staging area, because you might -> commit changes you forgot you made. (Going back to snapshots, -> you might get the extra with incomplete makeup walking on -> the stage for the snapshot because you used `-a`!) -> Try to stage things manually, -> or you might find yourself searching for "git undo commit" more -> than you would like! +> Piensa en Git como si tomara instantáneas de cambios durante la vida de un proyecto, +> `git add` especifica *qué* irá en una instantánea +> (poniendo cosas en el **staging area**), +> y `git commit` entonces *realmente toma* la instantánea, y +> hace un registro permanente de esto (como un **commit**). +> Si no tienes nada en el staging area cuando escribes `git commit`, +> Git te pedirá que uses `git commit -a` o `git commit --all`, +> que es como reunir ¡*a todos* para la foto! +> Sin embargo, es casi siempre mejor +> agregar explícitamente cosas al **staging area**, porque podrías +> hacer **commit** de cambios que habías olvidado. (Ir atrás en las instantáneas, +> podrías obtener el extra con maquillaje incompleto caminando sobre +> la etapa de la instantánea porque usaste `-a`!) +> Trata de organizar las cosas manualmente +> o podrías verte buscando "git undo commit" más +> de lo que te gustaría! {: .callout} ![The Git Staging Area](../fig/git-staging-area.svg) -Let's watch as our changes to a file move from our editor -to the staging area -and into long-term storage. -First, -we'll add another line to the file: +Veamos cómo nuestros cambios a un archivo se mueven de nuestro editor +al área de ensayo +y luego al almacenamiento de largo plazo. +Primero, +agregamos otra línea al archivo: ~~~ $ nano mars.txt @@ -390,6 +390,7 @@ diff --git a/mars.txt b/mars.txt index 315bf3a..b36abfd 100644 --- a/mars.txt +++ b/mars.txt +@@ -1,2 +1,3 @@ @@ -1,2 +1,3 @@ Cold and dry, but everything is my favorite color The two moons may be a problem for Wolfman @@ -397,11 +398,11 @@ index 315bf3a..b36abfd 100644 ~~~ {: .output} -So far, so good: -we've added one line to the end of the file -(shown with a `+` in the first column). -Now let's put that change in the staging area -and see what `git diff` reports: +Hasta aquí, todo bien: +hemos agregado una línea al final del archivo +(mostrado con un `+` en la primera columna). +Ahora pongamos el cambio en el **staging area** +y veamos lo que reporta `git diff`: ~~~ $ git add mars.txt @@ -409,12 +410,12 @@ $ git diff ~~~ {: .bash} -There is no output: -as far as Git can tell, -there's no difference between what it's been asked to save permanently -and what's currently in the directory. -However, -if we do this: +No hay salida: +en lo que Git puede decir, +no hay diferencia entre lo que se pidió guardar permanentemente +y lo que actualmente está en el directorio. +Sin embargo, +si hacemos esto: ~~~ $ git diff --staged @@ -433,10 +434,10 @@ index 315bf3a..b36abfd 100644 ~~~ {: .output} -it shows us the difference between -the last committed change -and what's in the staging area. -Let's save our changes: +esto nos muestra la diferencia entre +el último cambio que sí hizo **commit** +y lo que está en el **staging area**. +Guardemos nuestros cambios: ~~~ $ git commit -m "Discuss concerns about Mars' climate for Mummy" @@ -449,7 +450,7 @@ $ git commit -m "Discuss concerns about Mars' climate for Mummy" ~~~ {: .output} -check our status: +revisa nuestro estatus: ~~~ $ git status @@ -462,7 +463,7 @@ nothing to commit, working directory clean ~~~ {: .output} -and look at the history of what we've done so far: +y mira en la historia lo que hemos hecho hasta aquí: ~~~ $ git log @@ -490,33 +491,33 @@ Date: Thu Aug 22 09:51:46 2013 -0400 ~~~ {: .output} -> ## Word-based diffing +> ## Diferencias basadas en palabra > -> Sometimes, e.g. in the case of the text documments a line-wise -> diff is too coarse. That is where the `--color-words` option of -> `git diff` comes in very useful as it highlights the changed -> words using colors. +> A veces, en el caso de documentos de texto un diff en línea +> es demasiado caótico. Es ahí donde la opción `--color-words` de +> `git diff` se vuelve muy útil ya que resalta las palabras +> modificadas usando colores. {: .callout} -> ## Paging the Log +> ## Paginación del Registro > -> When the output of `git log` is too long to fit in your screen, -> `git` uses a program to split it into pages of the size of your screen. -> When this "pager" is called, you will notice that the last line in your -> screen is a `:`, instead of your usual prompt. +> Cuando la salida de `git log` es demasiado larga para caber en tu pantalla, +> `git` usa un programa para dividir en páginas del tamaño de tu pantalla. +> Cuando este "paginador" es llamado, notarás que la última línea de tu +> pantalla es un `:`, en lugar de tu prompt de siempre. > -> * To get out of the pager, press `q`. -> * To move to the next page, press the space bar. -> * To search for `some_word` in all pages, type `/some_word` -> and navigate through matches pressing `n`. +> * Para salir del paginador, presiona `q`. +> * Para mover a la siguiente página, presiona la barra espaciadora. +> * Para buscar `alguna_palabra` en todas las páginas, escribe `/alguna_palabra` +> y navega entre las coincidencias presionando `n` (next). {: .callout} -> ## Limit Log Size +> ## Tamaño Límite del Registro > -> To avoid having `git log` cover your entire terminal screen, you can limit the -> number of commits that Git lists by using `-N`, where `N` is the number of -> commits that you want to view. For example, if you only want information from -> the last commit you can use: +> Para evitar que `git log` cubra toda la pantalla de tu terminal, puedes limitar el +> número de **commits** que Git lista usando `-N`, donde `N` es el número de +> **commits** que tu quieres ver. Por ejemplo, si sólo quieres información de +> el último **commit**, puedes usar: > > ~~~ > $ git log -1 @@ -532,8 +533,8 @@ Date: Thu Aug 22 09:51:46 2013 -0400 > ~~~ > {: .output} > -> You can also reduce the quantity of information using the -> `--oneline` option: +> Puedes reducir la cantidad de información usando la +> opción `--oneline`: > > ~~~ > $ git log --oneline @@ -546,8 +547,8 @@ Date: Thu Aug 22 09:51:46 2013 -0400 > ~~~ > {: .output} > -> You can also combine the `--oneline` options with others. One useful -> combination is: +> Puedes combinar las opciones `--oneline` con otras. Una combinación +> útil es: > > ~~~ > $ git log --oneline --graph --all --decorate @@ -561,12 +562,12 @@ Date: Thu Aug 22 09:51:46 2013 -0400 > {: .output} {: .callout} -> ## Directories +> ## Directorios > -> Two important facts you should know about directories in Git. +> Dos hechos importantes que deberías saber acerca de directorios en Git. > -> 1. Git does not track directories on their own, only files within them. -> Try it for yourself: +> 1. Git no rastrea directorios por su cuenta, sólo archivos dentro de ellos. +> Inténtalo tú mismo: > > ~~~ > $ mkdir directory @@ -576,51 +577,51 @@ Date: Thu Aug 22 09:51:46 2013 -0400 > ~~~ > {: .bash} > -> Note, our newly created empty directory `directory` does not appear in -> the list of untracked files even if we explicitly add it (_via_ `git add`) to our -> repository. This is the reason why you will sometimes see `.gitkeep` files -> in otherwise empty directories. Unlike `.gitignore`, these files are not special -> and their sole purpose is to populate a directory so that Git adds it to -> the repository. In fact, you can name such files anything you like. +> Nota, nuestro nuevo y vació directorio `directory` no aparece en +> la lista de archivos no rastreados aún si nosotros explícitamente lo agregamos(_via_ `git add`) a nuestro +> repositorio. Esta es la razón por la que algunas veces verás archivos `.gitkeep` +> en directorios vacíos. A diferencia de `.gitignore`, estos archivos no son especiales +> y su único propósito es poblar un directorio para que Git lo agregue +> al repositorio. En efecto, podrías nombrar estos archivos como quieras. > > {:start="2"} -> 2. If you create a directory in your Git repository and populate it with files, -> you can add all files in the directory at once by: +> 2. Si creas un directorio en tu repositorio Git y poblas éste con archivos, +> podrás agregar todos los archivos en el directorio a la vez haciendo: > > ~~~ -> git add +> git add 1 > ~~~ > {: .bash} > {: .callout} -To recap, when we want to add changes to our repository, -we first need to add the changed files to the staging area -(`git add`) and then commit the staged changes to the -repository (`git commit`): +Recapitulando, cuando queremos agregar cambios a nuestro repositorio, +primero necesitamos agregar los archivos cambiados al área de ensayo +(`git add`) y luego hacer un **commit** de los cambios al +repositorio (`git commit`): ![The Git Commit Workflow](../fig/git-committing.svg) -> ## Choosing a Commit Message +> ## Escogiendo un Mensaje para el **Commit** > -> Which of the following commit messages would be most appropriate for the -> last commit made to `mars.txt`? +> ¿Cuál de los siguientes mensajes de un **commit** debería ser más apropiado para el +> último **commit** hecho a `mars.txt`? > > 1. "Changes" > 2. "Added line 'But the Mummy will appreciate the lack of humidity' to mars.txt" > 3. "Discuss effects of Mars' climate on the Mummy" > -> > ## Solution -> > Answer 1 is not descriptive enough, -> > and answer 2 is too descriptive and redundant, -> > but answer 3 is good: short but descriptive. +> > ## Solución +> > La respuesta 1 no es suficientemente descriptiva, +> > y la respuesta 2 es demasiado descriptiva y redundante, +> > pero la respuesta 3 es buena: corta pero descriptiva. > {: .solution} {: .challenge} -> ## Committing Changes to Git +> ## Haciendo Commit de Cambios a Git > -> Which command(s) below would save the changes of `myfile.txt` -> to my local Git repository? +> ¿Cuál comando(s) de abajo deberían guardar los cambios de `myfile.txt` +> a mi repositorio local Git? > > 1. `$ git commit -m "my recent changes"` > @@ -632,30 +633,30 @@ repository (`git commit`): > > 4. `$ git commit -m myfile.txt "my recent changes"` > -> > ## Solution +> > ## Solución > > -> > 1. Would only create a commit if files have already been staged. -> > 2. Would try to create a new repository. -> > 3. Is correct: first add the file to the staging area, then commit. -> > 4. Would try to commit a file "my recent changes" with the message myfile.txt. +> > 1. Debería crear solamente un **commit** si los archivos ya han sido organizados. +> > 2. Trataría de crear un nuevo respositorio. +> > 3. Es correcto: primero agrega el archivo al **staging area**, luego hace **commit**. +> > 4. Intentaría hacer **commit** al archivo "my recent changes" con el mensaje myfile.txt. > {: .solution} {: .challenge} -> ## Committing Multiple Files +> ## Haciendo **Commit** a Multiples Archivos > -> The staging area can hold changes from any number of files -> that you want to commit as a single snapshot. +> El **staging area** puede tener cambios de cualquier número de archivos +> que quieras hacer **commit** como una sóla instantanea. > -> 1. Add some text to `mars.txt` noting your decision -> to consider Venus as a base -> 2. Create a new file `venus.txt` with your initial thoughts -> about Venus as a base for you and your friends -> 3. Add changes from both files to the staging area, -> and commit those changes. +> 1. Agrega algún texto a `mars.txt` anotando tu decisión +> para considerar Venus como base +> 2. Crea un nuevo archivo `venus.txt` con tus pensamientos iniciales +> acerca de Venus como base para tí y tus amigos +> 3. Agrega los cambios de ambos archivos al **staging area**, +> y haz un **commit** de esos cambios. > -> > ## Solution +> > ## Solución > > -> > First we make our changes to the `mars.txt` and `venus.txt` files: +> > Primero haremos nuestros cambios a los archivos `mars.txt` y `venus.txt`: > > ~~~ > > $ nano mars.txt > > $ cat mars.txt @@ -674,19 +675,19 @@ repository (`git commit`): > > Venus is a nice planet and I definitely should consider it as a base. > > ~~~ > > {: .output} -> > Now you can add both files to the staging area. We can do that in one line: +> > Ahora puedes agregar ambos archivos al **staging area**. Podemos hacer esto en una sóla línea: > > > > ~~~ > > $ git add mars.txt venus.txt > > ~~~ > > {: .bash} -> > Or with multiple commands: +> > O con varios comandos: > > ~~~ > > $ git add mars.txt > > $ git add venus.txt > > ~~~ > > {: .bash} -> > Now the files are ready to commit. You can check that using `git status`. If you are ready to commit use: +> > Ahora los archivos están listos para hacer **commit**. Puedes verificar esto usando `git status`. Si estás listo para hacer **commit** usa: > > ~~~ > > $ git commit -m "Write plans to start a base on Venus" > > ~~~ @@ -701,37 +702,37 @@ repository (`git commit`): > {: .solution} {: .challenge} -> ## Author and Committer -> -> For each of the commits you have done, Git stored your name twice. -> You are named as the author and as the committer. You can observe -> that by telling Git to show you more information about your last -> commits: +> ## Author y Committer +> Para cada uno de los **commits** que hayas hecho, Git almacenó tu nombre 2 veces. +> Tú eres nombrado como el **author** y el **committer**. Puedes observar +> esto, diciendo a Git que te muestre más información acerca de tus últimos +> **commits**: > > ~~~ > $ git log --format=full > ~~~ > {: .bash} > -> When commiting you can name someone else as the author: +> Cuando haces **commit** puedes nombrar a alguien más como el **author**: > > ~~~ > $ git commit --author="Vlad Dracula " > ~~~ > {: .bash} > -> Create a new repository and create two commits: one without the -> `--author` option and one by naming a colleague of yours as the -> author. Run `git log` and `git log --format=full`. Think about ways -> how that can allow you to collaborate with your colleagues. +> Crea un nuevo repositorio y crea dos **commits**: uno sin la +> opción `--author` y uno nombrando a un colega tuyo como el +> **author**. Ejecuta `git log` y `git log --format=full`. Piensa acerca de formas de +> cómo esto puede permitir colaborar con tus colegas. > -> > ## Solution +> > ## Solución > > > > ~~~ > > $ git add me.txt > > $ git commit -m "Update Vlad's bio." --author="Frank N. Stein " > > ~~~ > > {: .bash} +> > > > ~~~ > > [master 4162a51] Update Vlad's bio. > > Author: Frank N. Stein @@ -750,6 +751,7 @@ repository (`git commit`): > > > > Vlad's initial bio. > > ~~~ +> > > > {: .output} > {: .solution} {: .challenge} diff --git a/_episodes/05-history.md b/_episodes/05-history.md index 1f99899bc8..9372edaaa3 100644 --- a/_episodes/05-history.md +++ b/_episodes/05-history.md @@ -1,28 +1,29 @@ --- -title: Exploring History +title: Explorando el **History** teaching: 25 exercises: 0 questions: -- "How can I identify old versions of files?" -- "How do I review my changes?" -- "How can I recover old versions of files?" +- "¿Cómo puedo identificar versiones anteriores de archivos?" +- "¿Cómo puedo revisar mis cambios?" +- "¿Cómo puedo recuperar versiones anteriores de archivos?" objectives: -- "Explain what the HEAD of a repository is and how to use it." -- "Identify and use Git commit numbers." -- "Compare various versions of tracked files." -- "Restore old versions of files." +- "Explicar qué es el **HEAD** de un repositorio y cómo usarlo." +- "Identificar y usar el número de **commit** the Git." +- "Comparar varias versiones de archivos." +- "Restaurar versiones anteriores de archivos." keypoints: -- "`git diff` displays differences between commits." -- "`git checkout` recovers old versions of files." +- "`git diff` despliega diferencias entre **commits**." +- "`git checkout` recupera versiones anteriores de archivos." --- -As we saw in the previous lesson, we can refer to commits by their -identifiers. You can refer to the _most recent commit_ of the working -directory by using the identifier `HEAD`. -We've been adding one line at a time to `mars.txt`, so it's easy to track our -progress by looking, so let's do that using our `HEAD`s. Before we start, -let's make a change to `mars.txt`. +Como vimos en la lección anterior, podemos referirnos a los **commits** por sus +identificadores. Puedes referirte a el _commit más reciente_ del directorio de trabajo +usando el identificador `HEAD`. + +Hemos estado agregando una línea a la vez a `mars.txt`, por lo que es fácil rastrear nuestro +progreso, así que hagamos eso usando `HEAD`. Antes de iniciar, +hagamos un cambio en `mars.txt`. ~~~ $ nano mars.txt @@ -38,7 +39,7 @@ An ill-considered change ~~~ {: .output} -Now, let's see what we get. +Ahora, veamos lo que tenemos. ~~~ $ git diff HEAD mars.txt @@ -58,18 +59,17 @@ index b36abfd..0848c8d 100644 ~~~ {: .output} -which is the same as what you would get if you leave out `HEAD` (try it). The -real goodness in all this is when you can refer to previous commits. We do -that by adding `~1` to refer to the commit one before `HEAD`. +Lo mismo obtendrías si omites 'HEAD` (intentalo). +La verdadera bondad en todo esto es cuando puedes referirte a **commits** previos. Hacemos +esto agregando `~1` para referirnos al **commit** anterior de `HEAD`. ~~~ $ git diff HEAD~1 mars.txt ~~~ {: .bash} -If we want to see the differences between older commits we can use `git diff` -again, but with the notation `HEAD~1`, `HEAD~2`, and so on, to refer to them: - +Si queremos ver las diferencias entre **commits** anteriores podemos usar `git diff` +nuevamente, pero con la notación `HEAD~1`,`HEAD~2`, y así sucesivamente, para referirse a ellos: ~~~ $ git diff HEAD~2 mars.txt @@ -88,7 +88,8 @@ index df0654a..b36abfd 100644 ~~~ {: .output} -We could also use `git show` which shows us what changes we made at an older commit as well as the commit message, rather than the _differences_ between a commit and our working directory that we see by using `git diff`. + +También podríamos usar `git show`, que nos muestra qué cambios hemos realizado en un **commit** anterior así como el mensaje del **commit**, en lugar de las _diferencias_ entre un **commit** y nuestro directorio de trabajo, que vemos usando `git diff`. ~~~ $ git show HEAD~2 mars.txt @@ -112,24 +113,25 @@ index df0654a..315bf3a 100644 ~~~ {: .output} -In this way, -we can build up a chain of commits. -The most recent end of the chain is referred to as `HEAD`; -we can refer to previous commits using the `~` notation, -so `HEAD~1` (pronounced "head minus one") -means "the previous commit", -while `HEAD~123` goes back 123 commits from where we are now. - -We can also refer to commits using -those long strings of digits and letters -that `git log` displays. -These are unique IDs for the changes, -and "unique" really does mean unique: -every change to any set of files on any computer -has a unique 40-character identifier. -Our first commit was given the ID + +De este modo, +podemos construir una cadena de **commits**. +El más reciente de la cadena es referido como `HEAD`; +podemos referirnos a **commits** anteriores utilizando la notación `~`, +así `HEAD~1` (pronunciado "head minus one") +significa "el commit anterior", +mientras que 'HEAD~123` regresa 123 **commits** desde donde estamos ahora. + +También podemos referirnos a los commits usando +esas largas cadenas de dígitos y letras +que `git log` despliega. +Estos son ID únicos para los cambios, +y "unique" realmente significa único: +cada cambio a cualquier conjunto de archivos en cualquier computadora +tiene un identificador único de 40 caracteres. +Nuestro primer **commit** recibió el ID `f22b25e3233b4645dabd0d81e651fe074bd8e73b`, -so let's try this: +así que probemos esto: ~~~ $ git diff f22b25e3233b4645dabd0d81e651fe074bd8e73b mars.txt @@ -148,9 +150,10 @@ index df0654a..b36abfd 100644 ~~~ {: .output} -That's the right answer, -but typing out random 40-character strings is annoying, -so Git lets us use just the first few characters: + +Esa es la respuesta correcta, +pero escribir cadenas aleatorias de 40 caracteres es molesto, +entonces Git nos permite usar solo los primeros caracteres: ~~~ $ git diff f22b25e mars.txt @@ -169,10 +172,11 @@ index df0654a..b36abfd 100644 ~~~ {: .output} -All right! So -we can save changes to files and see what we've changed—now how -can we restore older versions of things? -Let's suppose we accidentally overwrite our file: + +¡Todo bien! Asi que +podemos guardar cambios en los archivos y ver qué hemos cambiado ahora +¿cómo podemos restaurar versiones anteriores de las cosas? +Supongamos que accidentalmente sobrescribimos nuestro archivo: ~~~ $ nano mars.txt @@ -185,8 +189,9 @@ We will need to manufacture our own oxygen ~~~ {: .output} -`git status` now tells us that the file has been changed, -but those changes haven't been staged: + +`git status` ahora nos dice que el archivo ha sido cambiado, +pero esos cambios no se han realizado: ~~~ $ git status @@ -205,8 +210,9 @@ no changes added to commit (use "git add" and/or "git commit -a") ~~~ {: .output} -We can put things back the way they were -by using `git checkout`: + +Podemos volver a poner las cosas tal como estaban +usando `git checkout`: ~~~ $ git checkout HEAD mars.txt @@ -221,13 +227,14 @@ But the Mummy will appreciate the lack of humidity ~~~ {: .output} -As you might guess from its name, -`git checkout` checks out (i.e., restores) an old version of a file. -In this case, -we're telling Git that we want to recover the version of the file recorded in `HEAD`, -which is the last saved commit. -If we want to go back even further, -we can use a commit identifier instead: + +Como puedes adivinar por su nombre, +`git checkout` recupera (es decir, restaura) una versión anterior de un archivo. +En este caso, +le estamos diciendo a Git que queremos recuperar la versión del archivo grabado en `HEAD`, +que es el último **commit** guardado. +Si queremos volver más allá, +podemos usar un identificador de **commit** en su lugar: ~~~ $ git checkout f22b25e mars.txt @@ -263,80 +270,85 @@ no changes added to commit (use "git add" and/or "git commit -a") ~~~ {: .output} -Notice that the changes are on the staged area. -Again, we can put things back the way they were -by using `git checkout`: + +Ten en cuenta que los cambios están en el **staging area** de almacenamiento. +Nuevamente, podemos volver a poner las cosas tal como estaban +usando `git checkout`: ~~~ $ git checkout -f master mars.txt ~~~ {: .bash} -> ## Don't Lose Your HEAD +> ## No puierdas tu HEAD > -> Above we used +> Arriba usamos > > ~~~ > $ git checkout f22b25e mars.txt > ~~~ > {: .bash} > -> to revert `mars.txt` to its state after the commit `f22b25e`. -> If you forget `mars.txt` in that command, Git will tell you that "You are in -> 'detached HEAD' state." In this state, you shouldn't make any changes. -> You can fix this by reattaching your head using ``git checkout master`` +> para revertir `mars.txt` a su estado después del **commit** `f22b25e`. +> Si olvidas `mars.txt` en ese comando, Git te dirá que "You are in +> 'detached HEAD' state". En este estado, no dno podrías hacer ningún cambio. +> Puedes arreglar esto volviendo a conectar tu **head** usando ``git checkout master`` {: .callout} -It's important to remember that -we must use the commit number that identifies the state of the repository -*before* the change we're trying to undo. -A common mistake is to use the number of -the commit in which we made the change we're trying to get rid of. -In the example below, we want to retrieve the state from before the most -recent commit (`HEAD~1`), which is commit `f22b25e`: + +Es importante recordar que +debemos usar el número de **commit** que identifica el estado del repositorio +*antes* del cambio que intentamos deshacer. +Un error común es usar el número de +**commit** en el cual hicimos el cambio del que estamos tratando de deshacer. +En el siguiente ejemplo, queremos recuperar el estado antes del más reciente +**commit** (`HEAD~1`), que es **commit** `f22b25e`: + ![Git Checkout](../fig/git-checkout.svg) -So, to put it all together, -here's how Git works in cartoon form: + +Así que, para poner todo junto, +aqui esta como Git trabaja en forma de dibujo: ![http://figshare.com/articles/How_Git_works_a_cartoon/1328266](../fig/git_staging.svg) -> ## Simplifying the Common Case +> ## Simplificando el caso común > -> If you read the output of `git status` carefully, -> you'll see that it includes this hint: +> Si lees la salida de `git status` detenidamente, +> verás que incluye esta sugerencia: > > ~~~ > (use "git checkout -- ..." to discard changes in working directory) > ~~~ > {: .bash} > -> As it says, -> `git checkout` without a version identifier restores files to the state saved in `HEAD`. -> The double dash `--` is needed to separate the names of the files being recovered -> from the command itself: -> without it, -> Git would try to use the name of the file as the commit identifier. +> Como deciamos, +> `git checkout` sin un identificador de versión restaura los archivos al estado guardado en `HEAD`. +> El doble guión `--` es necesario para separar los nombres de los archivos que se están recuperando +> desde el comando mismo: +> sin esto, +> Git intentaría usar el nombre del archivo como el identificador del **commit**. {: .callout} -The fact that files can be reverted one by one -tends to change the way people organize their work. -If everything is in one large document, -it's hard (but not impossible) to undo changes to the introduction -without also undoing changes made later to the conclusion. -If the introduction and conclusion are stored in separate files, -on the other hand, -moving backward and forward in time becomes much easier. -> ## Recovering Older Versions of a File +El hecho de que los archivos puedan revertirse uno por uno +tiende a cambiar la forma en que las personas organizan su trabajo. +Si todo está en un documento grande, +es difícil (pero no imposible) deshacer cambios a la introducción +sin deshacer los cambios posteriores a la conclusión. +Si la introducción y la conclusión se almacenan en archivos separados, +por otra parte, +retroceder y avanzar en el tiempo se vuelve mucho más fácil. + +> ## Recuperando versiones anteriores de un archivo > -> Jennifer has made changes to the Python script that she has been working on for weeks, and the -> modifications she made this morning "broke" the script and it no longer runs. She has spent -> ~ 1hr trying to fix it, with no luck... +> Jennifer ha realizado cambios en el **script** de Python en el que ha estado trabajando durante semanas, y las +> modificaciones que hizo esta mañana "corrompieron" el **script** y ya no funciona. Ella ha pasado +> ~ 1hr tratando de solucionarlo, sin tener suerte... > -> Luckily, she has been keeping track of her project's versions using Git! Which commands below will -> let her recover the last committed version of her Python script called +> Por suerte, ella ha estado haciendo un seguimiento de las versiones de su proyecto usando Git! ¿Cuáles comandos +> le permitirán recuperar la última versión estable de su **script** Python llamado > `data_cruncher.py`? > > 1. `$ git checkout HEAD` @@ -347,44 +359,45 @@ moving backward and forward in time becomes much easier. > > 4. `$ git checkout data_cruncher.py` > -> 5. Both 2 and 4 +> 5. Ambos 2 y 4 {: .challenge} -> ## Reverting a Commit + +> ## Revertir un commit > -> Jennifer is collaborating on her Python script with her colleagues and -> realizes her last commit to the group repository is wrong and wants to -> undo it. Jennifer needs to undo correctly so everyone in the group -> repository gets the correct change. `git revert [wrong commit ID]` -> will make a new commit that undoes Jennifer's previous wrong -> commit. Therefore `git revert` is different than `git checkout [commit -> ID]` because `checkout` is for local changes not committed to the -> group repository. Below are the right steps and explanations for -> Jennifer to use `git revert`, what is the missing command? +> Jennifer está colaborando en su **script** de Python con sus colegas y +> se da cuenta de que su último **commit** en el repositorio del grupo es incorrecto y quiere +> deshacerlo. Jennifer necesita deshacer correctamente para que todos en el repositorio +> del grupo tengan el cambio correcto. `git revert [ID de commit incorrecto]` +> hará un nuevo **commit** que va a deshacer el commit anterior erroneo de Jennifer. +> Por lo tanto, `git revert` es diferente de `git checkout [commit +> ID]` porque `checkout` es para cambios locales no comprometidos con el +> repositorio de grupo. A continuación se encuentran los pasos correctos y explicaciones para +> que Jennifer use `git revert`, ¿cuál es el comando que falta? > -> 1. ________ # Look at the git history of the project to find the commit ID +> 1. ________ # Mira el historial de git del proyecto para encontrar el ID del **commit** > -> 2. Copy the ID (the first few characters of the ID, e.g. 0b1d055). +> 2. Copia el ID ( los primeros caracteres del ID, e.g. 0b1d055). > > 3. `git revert [commit ID]` > -> 4. Type in the new commit message. +> 4. Escriba el nuevo mensaje del **commit**. > -> 5. Save and close +> 5. Salva y cierra {: .challenge} -> ## Understanding Workflow and History +> ## Entendiendo Workflow y History > -> What is the output of cat venus.txt at the end of this set of commands? +> ¿Cuál es la salida de cat venus.txt al final de este conjunto de comandos? > > ~~~ > $ cd planets -> $ nano venus.txt #input the following text: Venus is beautiful and full of love +> $ nano venus.txt #captura el siguiente texto: Venus is beautiful and full of love > $ git add venus.txt -> $ nano venus.txt #add the following text: Venus is too hot to be suitable as a base +> $ nano venus.txt #agrega el siguiente texto: Venus is too hot to be suitable as a base > $ git commit -m "Comment on Venus as an unsuitable base" > $ git checkout HEAD venus.txt -> $ cat venus.txt #this will print the contents of venus.txt to the screen +> $ cat venus.txt #esto imprimirá el contenido de venus.txt en la pantalla > ~~~ > {: .bash} > @@ -417,104 +430,104 @@ moving backward and forward in time becomes much easier. > ~~~ > {: .output} > -> > ## Solution +> > ## Solución > > -> > Line by line: +> > Vamos línea por línea > > ~~~ > > $ cd planets > > ~~~ > > {: .bash} -> > Enters into the 'planets' directory +> > Entra al directorio 'planets' > > > > ~~~ -> > $ nano venus.txt #input the following text: Venus is beautiful and full of love +> > $ nano venus.txt #agrega el siguiente texto: Venus is beautiful and full of love > > ~~~ > > {: .bash} -> > We created a new file and wrote a sentence in it, but the file is not tracked by git. +> > Creamos un nuevo archivo y escribimos una oración, pero el archivo no es rastreado por git. > > > > ~~~ > > $ git add venus.txt > > ~~~ > > {: .bash} -> > Now the file is staged. The changes that have been made to the file until now will be committed in the next commit. +> > Ahora el archivo está en escena. Los cambios que se han realizado en el archivo hasta ahora se confirmarán en el siguiente **commit**. > > > > ~~~ -> > $ nano venus.txt #add the following text: Venus is too hot to be suitable as a base +> > $ nano venus.txt #agrega el siguiente texto: Venus is too hot to be suitable as a base > > ~~~ > > {: .bash} -> > The file has been modified. The new changes are not staged because we have not added the file. +> > El archivo ha sido modificado. Los nuevos cambios no se realizan porque no hemos agregado el archivo. > > > > ~~~ > > $ git commit -m "Comment on Venus as an unsuitable base" > > ~~~ > > {: .bash} -> > The changes that were staged (Venus is beautiful and full of love) have been committed. The changes that were not staged (Venus is too hot to be suitable as a base) have not. Our local working copy is different than the copy in our local repository. +> > Los cambios que se incluyeron (Venus is beautiful and full of love) se han confirmado. Los cambios que no se realizaron (Venus is too hot to be suitable as a base) no. Nuestra copia de trabajo local es diferente a la copia en nuestro repositorio local. > > > > ~~~ > > $ git checkout HEAD venus.txt > > ~~~ > > {: .bash} -> > With checkout we discard the changes in the working directory so that our local copy is exactly the same as our HEAD, the most recent commit. +> > Con el **checkout**, descartamos los cambios en el directorio de trabajo para que nuestra copia local sea exactamente la misma que nuestra HEAD, el más reciente **commit**. > > > > ~~~ -> > $ cat venus.txt #this will print the contents of venus.txt to the screen +> > $ cat venus.txt #esto imprimirá el contenido de venus.txt a la pantalla > > ~~~ > > {: .bash} -> > If we print venus.txt we will get answer 2. +> > Si imprimirmos venus.txt obtendremos la respuesta 2. > > > {: .solution} {: .challenge} -> ## Checking Understanding of `git diff` +> ## Comprobando lo que entendiste de `git diff` > -> Consider this command: `git diff HEAD~3 mars.txt`. What do you predict this command -> will do if you execute it? What happens when you do execute it? Why? +> Considera este comando: `git diff HEAD~3 mars.txt`. ¿Qué predices que hará este comando si lo ejecutas? ¿Qué sucede cuando lo ejecutas? ¿Por qué? > -> Try another command, `git diff [ID] mars.txt`, where [ID] is replaced with -> the unique identifier for your most recent commit. What do you think will happen, -> and what does happen? +> Prueba éste otro comando, `git diff [ID] mars.txt`, donde [ID] es +> el identificador único para tu commit más reciente. ¿Qué piensas tú que sucederá, +> y qué es lo que pasa? {: .challenge} -> ## Getting Rid of Staged Changes +> ## Deshacer los cambios almacenados > -> `git checkout` can be used to restore a previous commit when unstaged changes have -> been made, but will it also work for changes that have been staged but not committed? -> Make a change to `mars.txt`, add that change, and use `git checkout` to see if -> you can remove your change. +> `git checkout` puede usarse para restaurar un **commit** anterior cuando cambios no marcados se han +> hecho, pero también funcionará para los cambios que se han realizado pero no se han confirmado? +> Haz un cambio a `mars.txt`, agrega un cambio y use` git checkout` para ver si +> puedes eliminar tu cambio. {: .challenge} -> ## Explore and Summarize Histories +> ## Explorar y resumir el History > -> Exploring history is an important part of git, often it is a challenge to find -> the right commit ID, especially if the commit is from several months ago. +> Explorar el **history** es una parte importante de git, a menudo es un desafío encontrar +> el ID de confirmación correcto, especialmente si el **commit** es de hace varios meses. > -> Imagine the `planets` project has more than 50 files. -> You would like to find a commit with specific text in `mars.txt` is modified. -> When you type `git log`, a very long list appeared, -> How can you narrow down the search? +> Imagina que el proyecto `planets` tiene más de 50 archivos. +> Deseas encontrar un **commit** con texto específico en `mars.txt`. +> Cuando escribes `git log`, apareció una lista muy larga, +> ¿Cómo puede reducir la búsqueda? > -> Recorded that the `git diff` command allow us to explore one specific file, -> e.g. `git diff mars.txt`. We can apply the similar idea here. +> Recuerda que el comando `git diff` nos permite explorar un archivo específico, +> p. ej. `git diff mars.txt`. Podemos aplicar la idea similar aquí. > > ~~~ > $ git log mars.txt > ~~~ > {: .bash} > -> Unfortunately some of these commit messages are very ambiguous e.g. `update files`. -> How can you search through these files? +> Desafortunadamente, algunos de estos mensajes de los **commits** son muy ambiguos, p. Ej. `update files`. +> ¿Cómo puedes buscar a través de estos archivos? > -> Both `git diff` and `git log` are very useful and they summarize different part of the history for you. -> Is that possible to combine both? Let's try the following: +> Tanto `git diff` y` git log` son muy útiles y resumen una parte diferente del **history** para ti. +> ¿Es posible combinar ambos? Vamos a intentar lo siguiente: > > ~~~ > $ git log --patch mars.txt > ~~~ > {: .bash} > -> You should get a long list of output, and you should be able to see both commit messages and the difference between each commit. +> Deberías obtener una larga lista de resultados, y deberías poder ver los dos mensajes del **commit** y la diferencia entre cada +> **commit**. > -> Question: What does the following command do? +> Pregunta: ¿Qué hace el siguiente comando? > > ~~~ > $ git log --patch HEAD~3 *.txt diff --git a/_episodes/06-ignore.md b/_episodes/06-ignore.md index 794098faa2..5cbde3f73f 100644 --- a/_episodes/06-ignore.md +++ b/_episodes/06-ignore.md @@ -1,20 +1,20 @@ --- -title: Ignoring Things +title: Ignorando cosas teaching: 5 exercises: 0 questions: -- "How can I tell Git to ignore files I don't want to track?" +- "¿Cómo puedo decirle a Git que ignore los archivos que no quiero rastrear?" objectives: -- "Configure Git to ignore specific files." -- "Explain why ignoring files can be useful." +- "Configure Git para ignorar archivos específicos." +- "Explica por qué ignorar los archivos puede ser útil." keypoints: -- "The `.gitignore` file tells Git what files to ignore." +- "El archivo `.gitignore` le dice a Git qué archivos ignorar." --- -What if we have files that we do not want Git to track for us, -like backup files created by our editor -or intermediate files created during data analysis. -Let's create a few dummy files: +¿Qué pasa si tenemos archivos que no queremos que Git rastree, +como archivos de copia de seguridad creados por nuestro editor +o archivos intermedios creados durante el análisis de datos?. +Vamos a crear algunos archivos ficticios: ~~~ $ mkdir results @@ -22,7 +22,7 @@ $ touch a.dat b.dat c.dat results/a.out results/b.out ~~~ {: .bash} -and see what Git says: +Mira lo que Git dice: ~~~ $ git status @@ -42,12 +42,12 @@ nothing added to commit but untracked files present (use "git add" to track) ~~~ {: .output} -Putting these files under version control would be a waste of disk space. -What's worse, -having them all listed could distract us from changes that actually matter, -so let's tell Git to ignore them. +Colocar estos archivos bajo el control de versiones sería un desperdicio de espacio en disco. +Y lo que es peor, +al tenerlos todos listados, podría distraernos de los cambios que realmente importan, +así que vamos a decirle a Git que los ignore. -We do this by creating a file in the root directory of our project called `.gitignore`: +Lo hacemos creando un archivo en el directorio raíz de nuestro proyecto llamado `.gitignore`: ~~~ $ nano .gitignore @@ -61,13 +61,13 @@ results/ ~~~ {: .output} -These patterns tell Git to ignore any file whose name ends in `.dat` -and everything in the `results` directory. -(If any of these files were already being tracked, -Git would continue to track them.) +Estos patrones le dicen a Git que ignore cualquier archivo cuyo nombre termine en `.dat` +y todo lo que haya en el directorio `results`. +(Si alguno de estos archivos ya estaba siendo rastreado, +Git seguirá rastreándolos.) -Once we have created this file, -the output of `git status` is much cleaner: +Una vez que hemos creado este archivo, +la salida de `git status` es mucho más limpia: ~~~ $ git status @@ -84,11 +84,11 @@ nothing added to commit but untracked files present (use "git add" to track) ~~~ {: .output} -The only thing Git notices now is the newly-created `.gitignore` file. -You might think we wouldn't want to track it, -but everyone we're sharing our repository with will probably want to ignore -the same things that we're ignoring. -Let's add and commit `.gitignore`: +Lo único que Git advierte ahora, es el archivo `.gitignore` recién creado. +Podrías pensar que no queremos rastrearlo, +pero todos aquellos con los que compartimos nuestro repositorio probablemente desearán +ignorar las mismas cosas que nosotros. +Vamos a agregar y hacer "commit" de `.gitignore`: ~~~ $ git add .gitignore @@ -103,7 +103,7 @@ nothing to commit, working directory clean ~~~ {: .output} -As a bonus, using `.gitignore` helps us avoid accidentally adding to the repository files that we don't want to track: +Como ventaja, usar `.gitignore` nos ayuda a evitar agregar accidentalmente al repositorio los archivos que no queremos rastrear: ~~~ $ git add a.dat @@ -117,10 +117,10 @@ Use -f if you really want to add them. ~~~ {: .output} -If we really want to override our ignore settings, -we can use `git add -f` to force Git to add something. For example, +Si realmente queremos anular la configuración de ignorar, +podemos usar `git add -f` para obligar a Git a añadir algo. Por ejemplo, `git add -f a.dat`. -We can also always see the status of ignored files if we want: +También podemos ver siempre el estado de los archivos ignorados si queremos: ~~~ $ git status --ignored @@ -141,9 +141,9 @@ nothing to commit, working directory clean ~~~ {: .output} -> ## Ignoring Nested Files +> ## Ignorar archivos anidados > -> Given a directory structure that looks like: +> Dado un directorio con la siguiente estructura: > > ~~~ > results/data @@ -151,52 +151,51 @@ nothing to commit, working directory clean > ~~~ > {: .bash} > -> How would you ignore only `results/plots` and not `results/data`? +> ¿Cómo ignorarías sólo `results/plots` y no `results/data`? > -> > ## Solution +> > ## Solución > > -> > As with most programming issues, there are a few ways that you -> > could solve this. If you only want to ignore the contents of -> > `results/plots`, you can change your `.gitignore` to ignore -> > only the `/plots/` subfolder by adding the following line to -> > your .gitignore: +> > Como ocurre con la mayoría de los problemas de programación, hay +> > varias maneras de resolver esto. Si sólo deseas ignorar el +> > contenido de `results/plots`, puedes cambiar tu `.gitignore` para +> > ignorar solamente la subcarpeta `/plots/` añadiendo la siguiente línea a su .gitignore: > > > > `results/plots/` > > -> > If, instead, you want to ignore everything in `/results/`, but wanted to track -> > `results/data`, then you can add `results/` to your .gitignore -> > and create an exception for the `results/data/` folder. -> > The next challenge will cover this type of solution. +> > Si, en cambio, deseas ignorar todo en `/results/`, pero deseas realizar el +> > seguimiento de `results/data`, puedes agregar `results/` a su .gitignore y +> > crear una excepción para la carpeta `results/data/`. +> > El siguiente reto cubrirá este tipo de solución. > > -> > Sometimes the `**` pattern comes in handy, too, which matches -> > multiple directory levels. E.g. `**/results/plots/*` would make git ignore -> > the `results/plots` directory in any root directory. +> > +> > A veces el patrón `**` viene muy bien para referirse a múltiples +> > niveles de directorio. E.g. `**/results/plots/*` hará que git ignore el +> > directorio `results/plots` en cualquier directorio raíz. > {: .solution} {: .challenge} -> ## Including Specific Files +> ## Incluyendo archivos específicos > -> How would you ignore all `.data` files in your root directory except for -> `final.data`? -> Hint: Find out what `!` (the exclamation point operator) does +> ¿Cómo ignorarías todos los archivos `.data` en tu directorio raíz, excepto` final.data`? +> Sugerencia: Descubre lo que `!` (el signo de exclamación) hace > -> > ## Solution +> > ## Solución > > -> > You would add the following two lines to your .gitignore: +> > Agrega las siguientes dos líneas a tu .gitignore: > > > > ~~~ -> > *.data # ignore all data files -> > !final.data # except final.data +> > *.data # ignora todo los archivos .data +> > !final.data # excepto final.data > > ~~~ -> > {: .output} +> > {: .bash} > > -> > The exclamation point operator will include a previously excluded entry. +> > El signo de exclamación incluirá una entrada previamente excluida. > {: .solution} {: .challenge} -> ## Ignoring all data Files in a Directory +> ## Ignorando todos los archivos de datos en un directorio > -> Given a directory structure that looks like: +> Dado un directorio con la siguiente estructura: > > ~~~ > results/data/position/gps/a.data @@ -207,19 +206,20 @@ nothing to commit, working directory clean > ~~~ > {: .bash} > -> What's the shortest `.gitignore` rule you could write to ignore all `.data` -> files in `result/data/position/gps`? Do not ignore the `info.txt`. +> ¿Cuál es la regla más corta en `.gitignore` para ignorar todos los archivos `.data` +> en `result/data/position/gps`? No ignores el archivo `info.txt`. > -> > ## Solution +> > ## Solución > > -> > Appending `results/data/position/gps/*.data` will match every file in `results/data/position/gps` that ends with `.data`. -> > The file `results/data/position/gps/info.txt` will not be ignored. +> > Agregando `results/data/position/gps/*.data` coincidirá con cada archivo en +> > `results/data/position/gps` que termine con `.data`. +> > El archivo `results/data/position/gps/info.txt` no será ignorado. > {: .solution} {: .challenge} -> ## The Order of Rules +> ## El orden de las reglas > -> Given a `.gitignore` file with the following contents: +> Dado un archivo `.gitignore` con el siguiente contenido: > > ~~~ > *.data @@ -227,33 +227,32 @@ nothing to commit, working directory clean > ~~~ > {: .bash} > -> What will be the result? +> ¿Cuál será el resultado? > -> > ## Solution +> > ## Solución > > -> > The `!` modifier will negate an entry from a previously defined ignore pattern. -> > Because the `!*.data` entry negates all of the previous `.data` files in the `.gitignore`, -> > none of them will be ignored, and all `.data` files will be tracked. +> > El modificador `!` anulará algún patrón ignorado previamente definido. +> > Debido a que la entrada `!*.data` anula todos los archivos` .data` anteriores en `.gitignore`, +> > ninguno de ellos será ignorado, y todos los archivos` .data` serán rastreados. > > > {: .solution} {: .challenge} -> ## Log Files +> ## Archivos de bitácora > -> You wrote a script that creates many intermediate log-files of the form `log_01`, `log_02`, `log_03`, etc. -> You want to keep them but you do not want to track them through `git`. +> Supón que escribiste un **script** que crea muchos archivos de registro con la estructura `log_01`, `log_02`, `log_03`, etc. Deseas conservarlos pero no rastrearlos a través de `git`. > -> 1. Write **one** `.gitignore` entry that excludes files of the form `log_01`, `log_02`, etc. +> 1. Escribe **una entrada** `.gitignore` que excluya los archivos con estructura `log_01`, `log_02`, etc. > -> 2. Test your "ignore pattern" by creating some dummy files of the form `log_01`, etc. +> 2. Prueba tu "patrón de ignorar" creando algunos archivos ficticios `log_01`, etc. > -> 3. You find that the file `log_01` is very important after all, add it to the tracked files without changing the `.gitignore` again. +> 3. Te das cuenta de que el archivo `log_01` es muy importante después de todo, así que lo tienes que agregar a los archivos rastreados sin cambiar el` .gitignore` de nuevo > -> 4. Discuss with your neighbor what other types of files could reside in your directory that you do not want to track and thus would exclude via `.gitignore`. +> 4. Discute con tu compañero de al lado qué otros tipos de archivos podrían residir en tu directorio que no deseas seguir y por tanto excluir a través de `.gitignore`. > -> > ## Solution +> > ## Solución > > -> > 1. append either `log_*` or `log*` as a new entry in your .gitignore -> > 3. track `log_01` using `git add -f log_01` +> > 1. Agrega `log_*` o `log*` como nueva entrada en tu .gitignore +> > 3. Rastrea `log_01` usando `git add -f log_01` > {: .solution} {: .challenge} diff --git a/_episodes/07-github.md b/_episodes/07-github.md index 9e93bba97d..df1db4f4b4 100644 --- a/_episodes/07-github.md +++ b/_episodes/07-github.md @@ -1,46 +1,36 @@ --- -title: Remotes in GitHub +title: Repositorios remotos en GitHub teaching: 30 exercises: 0 questions: -- "How do I share my changes with others on the web?" +- "¿Cómo puedo compartir los cambios con otros en el web?" objectives: -- "Explain what remote repositories are and why they are useful." -- "Push to or pull from a remote repository." +- "Explica qué es un repositorio remoto y por qué es útil." +- "Poner y tomar de un repositorio remoto" keypoints: -- "A local Git repository can be connected to one or more remote repositories." -- "Use the HTTPS protocol to connect to remote repositories until you have learned how to set up SSH." -- "`git push` copies changes from a local repository to a remote repository." -- "`git pull` copies changes from a remote repository to a local repository." +- "Un repositorio Git local puede ser conectado a uno o más repositorios remotos." +- "Usa el protocolo HTTPS para conectarte a un repositorio remoto hasta que hayas aprendido como hacerlo con SSH." +- "`git push` copia los cambios desde el repositorio local a un repositorio remoto." +- "`git pull` copia los cambios desde un repositorio remoto a un repositorio local." --- -Version control really comes into its own when we begin to collaborate with -other people. We already have most of the machinery we need to do this; the -only thing missing is to copy changes from one repository to another. +Cuando se trabaja en colaboración con otras personas es cuando el sistema de control de versiones alcanza su pleno potencial. Ya hemos visto la mayor parte de las herramientas que necesitamos para ello, tan sólo nos falta ver cómo copiar los cambios realizados de un repositorio a otro. -Systems like Git allow us to move work between any two repositories. In -practice, though, it's easiest to use one copy as a central hub, and to keep it -on the web rather than on someone's laptop. Most programmers use hosting -services like [GitHub](http://github.com), [BitBucket](http://bitbucket.org) or -[GitLab](http://gitlab.com/) to hold those master copies; we'll explore the pros -and cons of this in the final section of this lesson. +Sistemas como Git ya nos permiten mover el trabajo realizado entre dos repositorios cualesquiera. Sin embargo, en la práctica es más sencillo establecer uno de ellos como repositorio central y tenerlo en la red en lugar de tu computadora particular. La mayoría de desarrolladores usan servicios de alojamiento en la red, tales como [GitHub](http://github.com), [BitBucket](http://bitbucket.org) o [GitLab](http://gitlab.com/), para alojar ese repositorio central; en la última sección de esta lección exploraremos los pros y los contras de cada uno de ellos. -Let's start by sharing the changes we've made to our current project with the -world. Log in to GitHub, then click on the icon in the top right corner to -create a new repository called `planets`: +Empecemos por compartir con todos los demás los cambios que hemos realizado en nuestro proyecto actual. Para ello, ingresa en tu cuenta de GitHub y haz click en el icono que hay en la esquina superior derecha para crear un nuevo repositorio llamado `planets`: -![Creating a Repository on GitHub (Step 1)](../fig/github-create-repo-01.png) +![Creando un Repositorio en GitHub (Paso 1)](../fig/github-create-repo-01.png) -Name your repository "planets" and then click "Create Repository": +Dale a tu repositorio el nombre "planets" y haz click en "Create repository": -![Creating a Repository on GitHub (Step 2)](../fig/github-create-repo-02.png) +![Creando un Repositorio en GitHub (Paso 2)](../fig/github-create-repo-02.png) -As soon as the repository is created, GitHub displays a page with a URL and some -information on how to configure your local repository: +Tan pronto es creado el repositorio, GitHub muestra una página con una URL y algo de información sobre cómo configurar tu repositorio local. -![Creating a Repository on GitHub (Step 3)](../fig/github-create-repo-03.png) +![Creando un Repositorio en GitHub (Paso 3)](../fig/github-create-repo-03.png) -This effectively does the following on GitHub's servers: +Esto en realidad ejecuta lo siguiente en los servidores de GitHub: ~~~ $ mkdir planets @@ -49,46 +39,39 @@ $ git init ~~~ {: .bash} -Our local repository still contains our earlier work on `mars.txt`, but the -remote repository on GitHub doesn't contain any files yet: +Nuestro repositorio local contiene nuestro trabajo previo en `mars.txt`, pero el repositorio remoto en GitHub todavía no contiene ningún archivo: -![Freshly-Made GitHub Repository](../fig/git-freshly-made-github-repo.svg) +![Repositorio en GitHub recién creado](../fig/git-freshly-made-github-repo.svg) -The next step is to connect the two repositories. We do this by making the -GitHub repository a [remote]({{ page.root }}/reference/#remote) for the local repository. -The home page of the repository on GitHub includes the string we need to -identify it: +El siguiente paso es conectar los dos repositorios. Ello se consigue convirtiendo al repositorio en GitHub en un [repositorio remoto]({{ page.root }}/reference/#remote) del repositorio local. La página de inicio del repositorio en GitHub incluye la secuencia de caracteres que necesitamos para identificarlo: -![Where to Find Repository URL on GitHub](../fig/github-find-repo-string.png) +![Dónde encontrar la URL del Repositorio en GitHub](../fig/github-find-repo-string.png) -Click on the 'HTTPS' link to change the [protocol]({{ page.root }}/reference/#protocol) from -SSH to HTTPS. +Haz click en el enlace 'HTTPS' para cambiar el [protocol0]({{ page.root }}/reference/#protocol) de SSH a HTTPS. > ## HTTPS vs. SSH > -> We use HTTPS here because it does not require additional configuration. After -> the workshop you may want to set up SSH access, which is a bit more secure, by -> following one of the great tutorials from -> [GitHub](https://help.github.com/articles/generating-ssh-keys), -> [Atlassian/BitBucket](https://confluence.atlassian.com/display/BITBUCKET/Set+up+SSH+for+Git) -> and [GitLab](https://about.gitlab.com/2014/03/04/add-ssh-key-screencast/) -> (this one has a screencast). +>Usamos aquí HTTPS porque no necesita ninguna configuración adicional. +>Si en el curso quieres configurar el acceso mediante SSH, que es un poco más seguro, +>puedes seguir cualquiera de los excelentes tutoriales que existen en +>[GitHub](https://help.github.com/articles/generating-ssh-keys), +>[Atlassian/BitBucket](https://confluence.atlassian.com/display/BITBUCKET/Set+up+SSH+for+Git) y +>[GitLab](https://about.gitlab.com/2014/03/04/add-ssh-key-screencast/) +>(este último con capturas animadas de pantalla). {: .callout} -![Changing the Repository URL on GitHub](../fig/github-change-repo-string.png) +![Cambiando la URL del Repositorio en GitHub](../fig/github-change-repo-string.png) -Copy that URL from the browser, go into the local `planets` repository, and run -this command: +Copia dicha URL desde el navegador, ve al repositorio local `planets` y ejecuta allí este comando: ~~~ $ git remote add origin https://github.com/vlad/planets.git ~~~ {: .bash} -Make sure to use the URL for your repository rather than Vlad's: the only -difference should be your username instead of `vlad`. +Asegúrate de usar la URL de tu repositorio en lugar de la de vlad: la única diferencia debería ser tu nombre de usuario en lugar de `vlad`. -We can check that the command has worked by running `git remote -v`: +Podemos comprobar que el comando ha funcionado bien ejecutando `git remote -v`: ~~~ $ git remote -v @@ -101,11 +84,9 @@ origin https://github.com/vlad/planets.git (fetch) ~~~ {: .output} -The name `origin` is a local nickname for your remote repository. We could use -something else if we wanted to, but `origin` is by far the most common choice. +El nombre `origin` es un apodo local para tu repositorio remoto. Se puede usar cualquier otro nombre si se desea, pero `origin` es la elección más habitual. -Once the nickname `origin` is set up, this command will push the changes from -our local repository to the repository on GitHub: +Una vez seleccionado el apodo local `origin`, el siguiente comando enviará los cambios realizados en nuestro repositorio local al repositorio en GitHub: ~~~ $ git push origin master @@ -126,9 +107,9 @@ Branch master set up to track remote branch master from origin. > ## Proxy > -> If the network you are connected to uses a proxy there is a chance that your -> last command failed with "Could not resolve hostname" as the error message. To -> solve this issue you need to tell Git about the proxy: +> Si la red a la que estás conectado usa un proxy es posible que tu último +> comando fallara con el siguiente mensaje de error: "Could not resolve hostname". +> Para solucionarlo es necesario informar a Git sobre el proxy: > > ~~~ > $ git config --global http.proxy http://user:password@proxy.url @@ -136,8 +117,8 @@ Branch master set up to track remote branch master from origin. > ~~~ > {: .bash} > -> When you connect to another network that doesn't use a proxy you will need to -> tell Git to disable the proxy using: +> Si después te conectas a otra red que no usa un proxy es necesario decirle +> a Git que deshabilite el proxy: > > ~~~ > $ git config --global --unset http.proxy @@ -146,43 +127,43 @@ Branch master set up to track remote branch master from origin. > {: .bash} {: .callout} -> ## Password Managers +> ## Gestores de contraseñas > -> If your operating system has a password manager configured, `git push` will -> try to use it when it needs your username and password. For example, this -> is the default behavior for Git Bash on Windows. If you want to type your -> username and password at the terminal instead of using a password manager, -> type: +> Si tu sistema operativo tiene un gestor de contraseñas configurado, `git push` +> intentará usarlo cuando necesite un nombre de usuario y contraseña. Al menos +> ese es el comportamiento por defecto para Git Bash en Windows. +> Si quieres que haya que introducir el nombre de usuario y contraseña en la terminal, +> en lugar de usar el gestor de contraseñas, hay que ejecutar el siguiente +> comando en la terminal antes de lanzar `git push`: > > ~~~ > $ unset SSH_ASKPASS > ~~~ > {: .bash} > -> in the terminal, before you run `git push`. Despite the name, [git uses -> `SSH_ASKPASS` for all credential -> entry](http://git-scm.com/docs/gitcredentials#_requesting_credentials), so -> you may want to unset `SSH_ASKPASS` whether you are using git via SSH or -> https. +> A pesar de lo que se podría deducir por el nombre, [git usa `SSH_ASKPASS` +> para todas las peticiones de credenciales](http://git-scm.com/docs/gitcredentials#_requesting_credentials), +> tanto si se está usando git vía SSH como si se está usando vía https, por lo +> que es posible que quieras deshabilitarlo en ambos casos con `unset SSH_ASKPASS` . > -> You may also want to add `unset SSH_ASKPASS` at the end of your `~/.bashrc` -> to make git default to using the terminal for usernames and passwords. +> Otra alternativa es añadir `unset SSH_ASKPASS` al final de tu `~/.bashrc` para que +> git use por defecto la terminal para los nombres de usuario y las contraseñas. {: .callout} -Our local and remote repositories are now in this state: +Nuestros repositorios local y remoto se encuentran ahora en el siguiente estado: -![GitHub Repository After First Push](../fig/github-repo-after-first-push.svg) +![Repositorio en GitHub después del primer envío](../fig/github-repo-after-first-push.svg) -> ## The '-u' Flag +> ## La opción '-u' > -> You may see a `-u` option used with `git push` in some documentation. This -> option is synonymous with the `--set-upstream-to` option for the `git branch` -> command, and is used to associate the current branch with a remote branch so -> that the `git pull` command can be used without any arguments. To do this, -> simply use `git push -u origin master` once the remote has been set up. +> En la documentación puedes ver que en ocasiones se usa la opción `-u` con el comando `git push`. +> Esta opción es sinónimo de la opción `--set-upstream-to` para el comando `git branch` y se usa +> para asociar la rama actual con una rama remota, de modo que el comando `git pull` +> pueda usarse sin argumentos. Para hacer esto simplemente ejecuta `git push -u origin master` +> una vez que el repositorio remoto haya sido creado. {: .callout} -We can pull changes from the remote repository to the local one as well: +También podemos hacer **pull**, es decir, traernos cambios desde el repositorio remoto al repositorio local: ~~~ $ git pull origin master @@ -196,79 +177,77 @@ Already up-to-date. ~~~ {: .output} -Pulling has no effect in this case because the two repositories are already -synchronized. If someone else had pushed some changes to the repository on -GitHub, though, this command would download them to our local repository. +En este caso, hacer **pull** no ha tenido ningún efecto porque los dos repositorios están ya sincronizados. Por el contrario, si alguien antes hubiera subido con **push** algunos cambios al repositorio en GitHub, este comando los habría incorporado a nuestro repositorio local. -> ## GitHub GUI +> ## Interfaz gráfica de GitHub > -> Browse to your `planets` repository on GitHub. -> Under the Code tab, find and click on the text that says "XX commits" (where "XX" is some number). -> Hover over, and click on, the three buttons to the right of each commit. -> What information can you gather/explore from these buttons? -> How would you get that same information in the shell? +> Navega hasta tu repositorio `planets` en GitHub. +> En la pestaña Code, localiza el texto "XX commits" (donde "XX" es algún número) y haz click en él. +> Mueve el cursor sobre los tres botones que hay a la derecha de cada **commit**, y haz click en ellos. +> ¿Qué información puedes obtener/explorar con estos botones? +> ¿Cómo obtendrías la misma información en la terminal? > -> > ## Solution -> > The left-most button (with the picture of a clipboard) copies the full identifier of the commit to the clipboard. In the shell, ```git log``` will show you the full commit identifier for each commit. +> > ## Solución +> > El botón más a la izquierda (con el dibujo de un portapapeles) sirve para copiar en el portapapeles el identificador completo del **commit** en cuestión. En la terminal, ```git log``` muestra los identificadores completos de cada **commit**. > > -> > When you click on the middle button, you'll see all of the changes that were made in that particular commit. Green shaded lines indicate additions and red ones removals. In the shell we can do the same thing with ```git diff```. In particular, ```git diff ID1..ID2``` where ID1 and ID2 are commit identifiers (e.g. ```git diff a3bf1e5..041e637```) will show the differences between those two commits. +> > Haciendo click en el botón de en medio, se pueden ver todos los cambios efectuados con el **commit** en cuestión. Las líneas verdes sombreadas indican adiciones y las rojas eliminaciones. En la terminal se puede ver lo mismo con ```git diff```. En particular, ```git diff ID1..ID2``` donde ID1 y ID2 son identificadores de **commits** (e.g. ```git diff a3bf1e5..041e637```) mostrará las diferencias entre esos dos **commits**. > > -> > The right-most button lets you view all of the files in the repository at the time of that commit. To do this in the shell, we'd need to checkout the repository at that particular time. We can do this with ```git checkout ID``` where ID is the identifier of the commit we want to look at. If we do this, we need to remember to put the repository back to the right state afterwards! +> > El botón más a la derecha permite ver todos los archivos que existían en el repositorio en el momento del **commit** en cuestión. Para ver lo mismo en la terminal sería necesario hacer **checkout** del repositorio a ese momento del tiempo. Para ello se ejecutaría ```git checkout ID``` donde ID es el identificador del **commit** que queremos investigar. ¡Si se hace esto hay que acordarse luego de poner el repositorio de nuevo en el estado correcto! > {: .solution} {: .challenge} -> ## GitHub Timestamp +> ## Fecha y Hora en GitHub > -> Create a remote repository on GitHub. Push the contents of your local -> repository to the remote. Make changes to your local repository and push -> these changes. Go to the repo you just created on GitHub and check the -> [timestamps]({{ page.root }}/reference/#timestamp) of the files. How does GitHub record -> times, and why? +> Crea un repositorio remoto en GitHub. Haz **push** de los contenidos de tu repositorio local +> al remoto. Haz cambios en tu repositorio local y haz **push** de dichos cambios. +> Ve al repo recién creado en GitHub y comprueba las fechas y horas, también llamadas +> [timestamps]({{ page.root }}/reference/#timestamp) de los ficheros. ¿Cómo registra +> GitHub los tiempos, y por qué? > -> > ## Solution -> > Github displays timestamps in a human readable relative format (i.e. "22 hours ago" or "three weeks ago"). However, if you hover over the timestamp, you can see the exact time at which the last change to the file occurred. +> > ## Solución +> > Github muestra los tiempos en formato relativo legible para los humanos (i.e. "22 hours ago" or "three weeks ago"). Sin embargo, si mueves el cursor sobre un **timestamp**, podrás ver el tiempo exacto en el que se realizó el último cambio al fichero. > {: .solution} {: .challenge} > ## Push vs. Commit > -> In this lesson, we introduced the "git push" command. -> How is "git push" different from "git commit"? +> En esta lección hemos introducido el comando "git push". +> ¿En qué se diferencia "git push" de "git commit"? > -> > ## Solution -> > When we push changes, we're interacting with a remote repository to update it with the changes we've made locally (often this corresponds to sharing the changes we've made with others). Commit only updates your local repository. +> > ## Solución +> > Cuando enviamos cambios con **push**, estamos interaccionando con un repositorio remoto para actualizarlo con los cambios que hemos hecho localmente (a menudo esto supone compartir con otros los cambios realizados). Por el contrario, **commit** únicamente actualiza tu repositorio local. > {: .solution} {: .challenge} -> ## Fixing Remote Settings +> ## Corrigiendo ajustes en el repositorio remoto > -> It happens quite often in practice that you made a typo in the -> remote URL. This exercice is about how to fix this kind of issues. -> First start by adding a remote with an invalid URL: +> Es muy frecuente cometer un error al especificar la URL del repositorio remoto. +> Este ejercicio trata de cómo corregir este tipo de errores. +> Empecemos por añadir un repositorio remoto con una URL inválida: > > ~~~ > git remote add broken https://github.com/this/url/is/invalid > ~~~ > {: .bash} > -> Do you get an error when adding the remote? Can you think of a -> command that would make it obvious that your remote URL was not -> valid? Can you figure out how to fix the URL (tip: use `git remote -> -h`)? Don't forget to clean up and remove this remote once you are -> done with this exercise. +> ¿Obtienes un error al añadir el repositorio remoto? ¿Se te ocurre algún +> comando que hiciera obvio que la URL de tu repositorio remoto no es +> válida? ¿Se te ocurre cómo corregir la URL? (pista: usa `git remote +> -h`). No olvides vaciar y eliminar este repositorio remoto una vez +> hayas terminado este ejercicio. > -> > ## Solution -> > We don't see any error message when we add the remote (adding the remote tells git about it, but doesn't try to use it yet). As soon as we try to use ```git push``` we'll see an error message. The command ```git remote set-url``` allows us to change the remote's URL to fix it. +> > ## Solución +> > No aparece ningún error cuando añadimos el repositorio remoto (añadir un repositorio remoto informa a git sobre dicho repositorio, pero no intenta usarlo todavía). Sí que veremos un error en cuanto intentemos usarlo con ```git push```. El comando ```git remote set-url``` nos permite cambiar la URL del repositorio remoto para corregirla. > {: .solution} {: .challenge} -> ## GitHub License and README files +> ## Licencia GitHub y ficheros README > -> In this section we learned about creating a remote repository on GitHub, but when you initialized your -> GitHub repo, you didn't add a README.md or a license file. If you had, what do you think would have happened when -> you tried to link your local and remote repositories? +> En esta sección hemos aprendido cómo crear un repositorio remoto en GitHub, pero cuando lo hicimos +> no añadimos ningún fichero README.md ni ningún fichero de licencia. Si lo hubiéramos hecho, ¿qué crees que hubiera sucedido cuando +> intentaste enlazar tus repositorios local y remoto? > -> > ## Solution -> > In this case, since we already had a README file in our own (local) repository, we'd see a merge conflict (when git realises that there are two versions of the file and asks us to reconcile the differences). +> > ## Solución +> > En este caso, puesto que ya teníamos un fichero README en nuestro propio repositorio (local), habríamos visto un conficto de unión, conocido como **merge conflict** (que es cuando git se da cuenta de que hay dos versiones de un mismo fichero y nos pide que resolvamos las diferencias). > {: .solution} {: .challenge} diff --git a/_episodes/08-collab.md b/_episodes/08-collab.md index ecfffa845a..c485356958 100644 --- a/_episodes/08-collab.md +++ b/_episodes/08-collab.md @@ -1,54 +1,44 @@ --- -title: Collaborating -teaching: 25 +title: Trabajos en colaboración +teaching: 5 exercises: 0 questions: -- "How can I use version control to collaborate with other people?" +- "¿Cómo puedo usar el control de versiones para colaborar con otras personas?" objectives: -- "Clone a remote repository." -- "Collaborate pushing to a common repository." -keypoints: -- "`git clone` copies a remote repository to create a local repository with a remote called `origin` automatically set up." +- Clonar un repositorio remoto. +- Colaborar en crear un repositorio común. +keypoints: '`git clone` copia un repositorio remoto para crear un repositorio local llamado `origin` configurado automáticamente.' --- -For the next step, get into pairs. One person will be the "Owner" and the other -will be the "Collaborator". The goal is that the Collaborator add changes into -the Owner's repository. We will switch roles at the end, so both persons will -play Owner and Collaborator. +Para el siguiente paso, formen parejas. Una persona será el "dueño" y la otra el "colaborador". El objetivo es que el colaborador agregue cambios al repositorio del dueño. Vamos a cambiar roles al final, de modo que ambas personas puedan participar como dueño y colaborador -> ## Practicing By Yourself +> ## Practicando por tu cuenta > -> If you're working through this lesson on your own, you can carry on by opening -> a second terminal window. -> This window will represent your partner, working on another computer. You -> won't need to give anyone access on GitHub, because both 'partners' are you. +> Si estás trabajando en esta lección por tu cuenta, puedes hacerlo abriendo una segunda sesión en la +> ventana de la terminal. Esta ventana representará a tu compañero, trabajando en otra computadora. No necesitas darle acceso a nadie en GitHub, pues tu serás ambos "compañeros". {: .callout} -The Owner needs to give the Collaborator access. -On GitHub, click the settings button on the right, -then select Collaborators, and enter your partner's username. +El dueño debe dar acceso al colaborador. En GitHub, haz clic en el botón de configuración arriba a la derecha, +luego selecciona "Collaborators" e ingresa el nombre de tu colaborador. ![Adding Collaborators on GitHub](../fig/github-add-collaborators.png) -To accept access to the Owner's repo, the Collaborator -needs to go to [https://github.com/notifications](https://github.com/notifications). -Once there she can accept access to the Owner's repo. +Para aceptar la invitación de acceso al repositorio, el Colaborador +debe ingresar a [https://github.com/notifications](https://github.com/notifications). +Una vez allí, se puede aceptar la invitación a dicho repositorio. -Next, the Collaborator needs to download a copy of the Owner's repository to her - machine. This is called "cloning a repo". To clone the Owner's repo into -her `Desktop` folder, the Collaborator enters: +Luego, el colaborador debe descargar una copia del repositorio del dueño a su máquina. Esto se conoce como "clonar un repositorio". Para clonar el repositorio del dueño en su carpeta de `Desktop`, el colaborador debe correr las siguientes líneas: ~~~ $ git clone https://github.com/vlad/planets.git ~/Desktop/vlad-planets ~~~ {: .bash} -Replace 'vlad' with the Owner's username. +Remplazar 'vlad' con el nombre de usuario del dueño. ![After Creating Clone of Repository](../fig/github-collaboration.svg) -The Collaborator can now make a change in her clone of the Owner's repository, -exactly the same way as we've been doing before: +El colaborador puede ahora hacer cambios en la versión clonada del repositorio del dueño,en la misma forma en que se hacían previamente: ~~~ $ cd ~/Desktop/vlad-planets @@ -74,7 +64,7 @@ $ git commit -m "Add notes about Pluto" ~~~ {: .output} -Then push the change to the *Owner's repository* on GitHub: +Luego enviar, "push", los cambios hacia el *repositorio del dueño* en GitHub: ~~~ $ git push origin master @@ -88,19 +78,15 @@ Compressing objects: 100% (2/2), done. Writing objects: 100% (3/3), 306 bytes, done. Total 3 (delta 0), reused 0 (delta 0) To https://github.com/vlad/planets.git - 9272da5..29aba7c master -> master + 9272da5..29aba7c master -> master ~~~ {: .output} -Note that we didn't have to create a remote called `origin`: Git uses this -name by default when we clone a repository. (This is why `origin` was a -sensible choice earlier when we were setting up remotes by hand.) +Nota que no es necesario crear un directorio remoto llamado `origin`: Git utiliza este nombre de manera automática cuando clonamos un repositorio. (Esta es la razón por la cual `origin` era una opción sensata a la hora de configurar directorios remotos a mano). -Take a look to the Owner's repository on its GitHub website now (maybe you need -to refresh your browser.) You should be able to see the new commit made by the -Collaborator. +Ahora echa un vistazo al repositorio del dueño en su sitio de Github (quizás debas refrescar la página). Deberás ver el nuevo commit hecho por el colaborador. -To download the Collaborator's changes from GitHub, the Owner now enters: +Para descargar los cambios hechos por el colaborador desde GitHub, el dueño corre las siguientes líneas: ~~~ $ git pull origin master @@ -113,7 +99,7 @@ remote: Compressing objects: 100% (2/2), done. remote: Total 3 (delta 0), reused 3 (delta 0) Unpacking objects: 100% (3/3), done. From https://github.com/vlad/planets - * branch master -> FETCH_HEAD + * branch master -> FETCH_HEAD Updating 9272da5..29aba7c Fast-forward pluto.txt | 1 + @@ -122,67 +108,48 @@ Fast-forward ~~~ {: .output} -Now the three repositories (Owner's local, Collaborator's local, and Owner's on -GitHub) are back in sync. - -> ## A Basic Collaborative Workflow -> -> In practice, it is good to be sure that you have an updated version of the -> repository you are collaborating on, so you should `git pull` before making -> our changes. The basic collaborative workflow would be: -> -> * update your local repo with `git pull origin master`, -> * make your changes and stage them with `git add`, -> * commit your changes with `git commit -m`, and -> * upload the changes to GitHub with `git push origin master` -> -> It is better to make many commits with smaller changes rather than -> of one commit with massive changes: small commits are easier to -> read and review. +Ahora hay tres repositorios sincronizados (el local del Dueño, el local del colaborador y el del dueño en GitHub). + +> ## Un flujo de trabajo colaborativo básico +> +> En la practica, es bueno estar seguro que tienes una versión actualizada del repositorio en el que colaboras. Para ello, es bueno hacer un `git pull` antes de hacer cambios. El enfoque sería: +> +> +> * actualizar el repositorio local `git pull origin master`, +> * realizar cambios `git add`, +> * realizar un commit `git commit -m`, y +> * cargar las actualizaciones a GitHub con `git push origin master` +> +> Es mejor hacer varias actualizaciones pequeñas que un **commit** grande con cambios enormes. **Commits** pequeños son más fáciles de leer y revisar. {: .callout} -> ## Switch Roles and Repeat -> -> Switch roles and repeat the whole process. +> ## Cambiar roles +> +> Cambie los roles y repita todo el proceso. {: .challenge} -> ## Review Changes -> -> The Owner push commits to the repository without giving any information -> to the Collaborator. How can the Collaborator find out what has changed with -> command line? And on GitHub? -> -> > ## Solution -> > On the command line, the Collaborator can use ```git fetch origin master``` -> > to get the remote changes into the local repository, but without merging -> > them. Then by running ```git diff master origin/master``` the Collaborator -> > will see the changes output in the terminal. -> > -> > On GitHub, the Collaborator can go to their own fork of the repository and -> > look right above the light blue latest commit bar for a gray bar saying -> > "This branch is 1 commit behind Our-Respository:master." On the far right of -> > that gray bar is a Compare icon and link. On the Compare page the -> > Collaborator should change the base fork to their own repository, then click -> > the link in the paragraph above to "compare across forks", and finally -> > change the head fork to the main repository. This will show all the commits -> > that are different. +> ## Revisar Cambios +> +El dueño hace un **push** de los **commits** al repositorio sin dar información al colaborador. Cómo puede éste saberlo desde la linea de comandos y desde GitHub? +> +>> ## Solution +>> +>> En la linea de comandos, el colaborador puede usar ```git fetch origin master``` para acceder a los cambios remotos en el repositorio local, sin hacer un **merge*. Luego, corriendo ```git diff master origin/master```, el colaborador verá los cambios en la terminal. +>> +>> En GitHub, el colaborador puede realizar su propio **fork** y hallar la barra gris que indica "This branch is 1 commit behind Our-Respository:master.". Lejos, a la derecha de la barra gris, hay un link para comparar. En la página para comparar, el colaborador debe cambiar el **fork** hacia su propio repositorio, luego hacer click en el link para "comparar entre forks" y, finalmente, cambiar el **fork** al repositorio principal. Esto mostrará todos los **commits** que sean distintos. > {: .solution} {: .challenge} -> ## Comment Changes in GitHub -> -> The Collaborator has some questions about one line change made by the Owner and -> has some suggestions to propose. -> -> With GitHub, it is possible to comment the diff of a commit. Over the line of -> code to comment, a blue comment icon appears to open a comment window. -> -> The Collaborator posts its comments and suggestions using GitHub interface. +> ## Comentar cambios en GitHub +> +> El colaborador tiene algunas preguntas sobre cambios en una línea hechos por el dueño. +> +> Con GitHub, es posible comentar la diferencia en un **commit**. Sobre la línea de código a comentar, el botón azul aparece para abrir una ventana. +> +> El colaborador postea los comentarios y sugerencias usando la interfaz de GitHub. {: .challenge} -> ## Version History, Backup, and Version Control -> -> Some backup software can keep a history of the versions of your files. They also -> allows you to recover specific versions. How is this functionality different from version control? -> What are some of the benifits of using version control, Git and GitHub? +> ## Historial de versiones, backup y control de versiones +> +> Algunos softwares que permiten hacer **backups** también permiten guardar un historial de versiones y recuperar versiones específicas. ¿Cómo es esta funcionalidad distinta del control de versiones? ¿Cuáles son los beneficios de usar control de versiones, Git y GitHub? {: .challenge} diff --git a/_episodes/09-conflict.md b/_episodes/09-conflict.md index 0274312322..998cc1b929 100644 --- a/_episodes/09-conflict.md +++ b/_episodes/09-conflict.md @@ -1,33 +1,28 @@ --- -title: Conflicts +title: Conflictos teaching: 15 exercises: 0 questions: -- "What do I do when my changes conflict with someone else's?" +- "¿Qué hago cuando mis cambios entran en conflicto con los de otra persona?" objectives: -- "Explain what conflicts are and when they can occur." -- "Resolve conflicts resulting from a merge." +- "Explicar qué son los conflictos y cuándo pueden ocurrir." +- "Resolver conflictos resultantes de una fusión." keypoints: -- "Conflicts occur when two or more people change the same file(s) at the same time." -- "The version control system does not allow people to overwrite each other's changes blindly, but highlights conflicts so that they can be resolved." +- "Los conflictos ocurren cuando dos o más personas cambian el mismo archivo(s) al mismo tiempo." +- "El sistema de control de versiones no permite a las personas sobreescribir ciegamente los +cambios del otro, pero resalta los conflictos para poder resolverlos." --- -As soon as people can work in parallel, it's likely someone's going to step on someone -else's toes. This will even happen with a single person: if we are working on -a piece of software on both our laptop and a server in the lab, we could make -different changes to each copy. Version control helps us manage these -[conflicts]({{ page.root }}/reference/#conflicts) by giving us tools to -[resolve]({{ page.root }}/reference/#resolve) overlapping changes. +Tan pronto como podemos trabajar en paralelo, es probable que alquien deshaga lo que otro hizo. Esto incluso es probable con una única persona: si estamos trabajando en un software al mismo tiempo en nuestra computadora portátil y un servidor en el laboratorio, podríamos hacer cambios diferentes a cada copia del trabajo. El control de versiones nos ayuda a manejar estos [confictos]({{ page.root }}/reference/#conflicts) al darnos herramientas para [resolver]({{ page.root }}/reference/#resolve) cambios que se hayan sobrelapado. -To see how we can resolve conflicts, we must first create one. The file -`mars.txt` currently looks like this in both partners' copies of our `planets` -repository: +Para ver cómo podemos resolver conflictos, primero debemos crear uno. Actualmente, el archivo `mars.txt` luce de la siguiente manera en dos copias de diferentes compañeros en nuestro repositorio `planetas`: ~~~ $ cat mars.txt ~~~ {: .bash} + ~~~ Cold and dry, but everything is my favorite color The two moons may be a problem for Wolfman @@ -35,7 +30,7 @@ But the Mummy will appreciate the lack of humidity ~~~ {: .output} -Let's add a line to one partner's copy only: +Agreguemos una línea únicamente a la copia de uno de los dos compañeros: ~~~ $ nano mars.txt @@ -43,6 +38,7 @@ $ cat mars.txt ~~~ {: .bash} + ~~~ Cold and dry, but everything is my favorite color The two moons may be a problem for Wolfman @@ -51,7 +47,9 @@ This line added to Wolfman's copy ~~~ {: .output} -and then push the change to GitHub: + +y luego hacer `push` al cambio a GitHub: + ~~~ $ git add mars.txt @@ -81,9 +79,9 @@ To https://github.com/vlad/planets ~~~ {: .output} -Now let's have the other partner -make a different change to their copy -*without* updating from GitHub: +Ahora haremos que el otro compañero +haga un cambio diferente a su copia +*sin* actualizar desde GitHub: ~~~ $ nano mars.txt @@ -91,6 +89,7 @@ $ cat mars.txt ~~~ {: .bash} + ~~~ Cold and dry, but everything is my favorite color The two moons may be a problem for Wolfman @@ -99,7 +98,8 @@ We added a different line in the other copy ~~~ {: .output} -We can commit the change locally: + +Podemos hacer **commit** del cambio localmente ~~~ $ git add mars.txt @@ -107,13 +107,15 @@ $ git commit -m "Add a line in my copy" ~~~ {: .bash} + ~~~ [master 07ebc69] Add a line in my copy 1 file changed, 1 insertion(+) -~~~ + ~~~ {: .output} -but Git won't let us push it to GitHub: + +pero Git no ns dejará hacer **push** a GitHub: ~~~ $ git push origin master @@ -133,12 +135,12 @@ hint: See the 'Note about fast-forwards' in 'git push --help' for details. ![The Conflicting Changes](../fig/conflict.svg) -Git detects that the changes made in one copy overlap with those made in the other -and stops us from trampling on our previous work. -What we have to do is pull the changes from GitHub, -[merge]({{ page.root }}/reference/#merge) them into the copy we're currently working in, -and then push that. -Let's start by pulling: +Git detecta que los cambios hechos en una copia se solapan con los cambios hechos en la otra +y nos impide pisotear nuestro trabajo previo. +Lo que debemos hacer es traer -`pull`- los cambios desde GitHub, +[unirlos]({{ page.root }}/reference/#merge) dentro de la copia en la que estamos trabajando actualmente, +y luego hacer `push` al resultado. +Empecemos haciendo `pull` a lo siguiente: ~~~ $ git pull origin master @@ -158,8 +160,8 @@ Automatic merge failed; fix conflicts and then commit the result. ~~~ {: .output} -`git pull` tells us there's a conflict, -and marks that conflict in the affected file: +`git pull` nos dice que hay un conflicto, +y marca ese conflicto en el archivo afectado: ~~~ $ cat mars.txt @@ -178,18 +180,18 @@ This line added to Wolfman's copy ~~~ {: .output} -Our change—the one in `HEAD`—is preceded by `<<<<<<<`. -Git has then inserted `=======` as a separator between the conflicting changes -and marked the end of the content downloaded from GitHub with `>>>>>>>`. -(The string of letters and digits after that marker -identifies the commit we've just downloaded.) +Nuestro cambio —señalado en `HEAD`— es precedido por `<<<<<<<`. +Luego, Git insertó `=======` como un separador entre los cambios conflictivos +y marcó el fin del contenido descargado desde GitHub con `>>>>>>>`. +(El código de letras y números luego del marcador +identifica el 'commit' que acabamos de descargar.) -It is now up to us to edit this file to remove these markers -and reconcile the changes. -We can do anything we want: keep the change made in the local repository, keep -the change made in the remote repository, write something new to replace both, -or get rid of the change entirely. -Let's replace both so that the file looks like this: +Ahora nosotros debemos editar este archivo para eliminar estos marcadores +y reconciliar los cambios. +Podemos hacer lo que querramos: mantener el cambio hecho en el repositorio local, mantener +el cambio hecho en el repositorio nuevo, redactar algo nuevo para reemplazar ambos, +o eliminar el cambio completamente. +Reemplacemos ambos de manera que el archivo quede así: ~~~ $ cat mars.txt @@ -204,9 +206,9 @@ We removed the conflict on this line ~~~ {: .output} -To finish merging, -we add `mars.txt` to the changes being made by the merge -and then commit: +Para finalizar la unión, +agregamos `mars.txt` a los cambios hechos por la unión +y luego hacemos 'commit': ~~~ $ git add mars.txt @@ -236,7 +238,7 @@ $ git commit -m "Merge changes from GitHub" ~~~ {: .output} -Now we can push our changes to GitHub: +Ahora podemos hacer 'push' a nuestros cambios a GitHub: ~~~ $ git push origin master @@ -254,9 +256,9 @@ To https://github.com/vlad/planets.git ~~~ {: .output} -Git keeps track of what we've merged with what, -so we don't have to fix things by hand again -when the collaborator who made the first change pulls again: +Git lleva el registro de qué hemos unificado con qué, +de manera que no debemos arreglar las cosas a mano nuevamente +cuando el colaborador que hizo el primer cambio hace **pull** de nuevo: ~~~ $ git pull origin master @@ -277,7 +279,7 @@ Fast-forward ~~~ {: .output} -We get the merged file: +Obtenemos el archivo unificado: ~~~ $ cat mars.txt @@ -292,51 +294,50 @@ We removed the conflict on this line ~~~ {: .output} -We don't need to merge again because Git knows someone has already done that. +No es necesario unificar el contenido nuevamente porque Git sabe que alguien ya ha hecho eso. -Git's ability to resolve conflicts is very useful, but conflict resolution -costs time and effort, and can introduce errors if conflicts are not resolved -correctly. If you find yourself resolving a lot of conflicts in a project, -consider these technical approaches to reducing them: +La habilidad de Git de resolver conflictos es muy útil, pero la resolución de confilctos +cuesta tiempo y esfuerzo, y puede introducir errores si los conflictos no son resueltos +correctamente. Si te encuentras resolviendo muchos conflictos en un proyecto +ten en cuenta estas aproximaciones técnicas para reducirlas: -- Pull from upstream more frequently, especially before starting new work -- Use topic branches to segregate work, merging to master when complete -- Make smaller more atomic commits -- Where logically appropriate, break large files into smaller ones so that it is - less likely that two authors will alter the same file simultaneously +- Hacer 'pull' con mayor frecuencia, especialmente antes de empezar una nueva tarea +- Usar ramas temáticas para separar trabajo, uniéndolas a la rama principal - `master`- cuando estén completas +- Hacer comentarios mas cortos y concisos +- Cuando sea apropiado, dividir archivos grandes en varios pequeños de manera que sea + menos probable que dos autores alteren el mismo archivo simultáneamente -Conflicts can also be minimized with project management strategies: +Los conflictos también pueden ser minimizados con estrategias de administración de proyectos: -- Clarify who is responsible for what areas with your collaborators -- Discuss what order tasks should be carried out in with your collaborators so - that tasks expected to change the same lines won't be worked on simultaneously -- If the conflicts are stylistic churn (e.g. tabs vs. spaces), establish a - project convention that is governing and use code style tools (e.g. - `htmltidy`, `perltidy`, `rubocop`, etc.) to enforce, if necessary +- Aclarar con tus colaboradores quién es responsable de cada área +- Discutir con tus colaboradores en qué orden deben realizarse las tareas para que + las tareas que puedan cambiar las mismas lineas no se trabajen simultáneamente. +- Si los conflictos son de estilo (e.g. tabulaciones vs. espacios), establecer una + convención que rija el proyecto y utilizar herramientas de estilo de código (e.g. + `htmltidy`, `perltidy`, `rubocop`, etc.) para forzarlas, si es necesario -> ## Solving Conflicts that You Create +> ## Solucionando conflictos creados por ti > -> Clone the repository created by your instructor. -> Add a new file to it, -> and modify an existing file (your instructor will tell you which one). -> When asked by your instructor, -> pull her changes from the repository to create a conflict, -> then resolve it. +> Clona el repositorio creado por tu instructor +> Agregarle un nuevo archivo +> y modificar un archivo existente (tu instructor te dirá cuál). +> Cuando tu instructor te lo pida, +> trae los cambios -haciendo 'pull'- desde el repositorio para crear un conflicto, +> y luego resuélvelo. {: .challenge} -> ## Conflicts on Non-textual files +> ## Conflictos en archivos no textuales > -> What does Git do -> when there is a conflict in an image or some other non-textual file -> that is stored in version control? +> ¿Qué hace Git +> cuando hay un conflicto en una imagen u otro archivo no de texto +> que está almacenado con control de versiones? > -> > ## Solution +> > ## Solución > > -> > Let's try it. Suppose Dracula takes a picture of Martian surface and -> > calls it `mars.jpg`. +> > Intentémoslo. Supón que **Dracula** toma una foto de la superficie de Marte y la llama `mars.jpg`. > > -> > If you do not have an image file of Mars available, you can create -> > a dummy binary file like this: +> > Si no tienes una imagen de Marte, puedes crear un archivo +> > binario de prueba de la siguiente manera: > > > > ~~~ > > $ head --bytes 1024 /dev/urandom > mars.jpg @@ -349,10 +350,10 @@ Conflicts can also be minimized with project management strategies: > > ~~~ > > {: .output} > > -> > `ls` shows us that this created a 1-kilobyte file. It is full of -> > random bytes read from the special file, `/dev/urandom`. +> > `ls` nos muestra que se creó un archivo de 1-kilobyte. Está lleno de bytes al azar +> > leídos a partir del archivo especial, `/dev/urandom`. > > -> > Now, suppose Dracula adds `mars.jpg` to his repository: +> > Ahora, supón que **Dracula** agrega `mars.jpg` a su repositorio: > > > > ~~~ > > $ git add mars.jpg @@ -367,9 +368,9 @@ Conflicts can also be minimized with project management strategies: > > ~~~ > > {: .output} > > -> > Suppose that Wolfman has added a similar picture in the meantime. -> > His is a picture of the Martian sky, but it is *also* called `mars.jpg`. -> > When Dracula tries to push, he gets a familiar message: +> > Supón que Wolfman agregó una imagen similar al mismo tiempo. +> > La suya es una imagen del cielo de Marte, pero *también* se llama `mars.jpg`. +> > Cuando **Dracula** intenta hacer push, recibe un mensaje familiar: > > > > ~~~ > > $ git push origin master @@ -388,15 +389,15 @@ Conflicts can also be minimized with project management strategies: > > ~~~ > > {: .output} > > -> > We've learned that we must pull first and resolve any conflicts: +> > Hemos aprendido que primero debemos hacer **pull** y resolver conflictos: > > > > ~~~ > > $ git pull origin master > > ~~~ > > {: .bash} > > -> > When there is a conflict on an image or other binary file, git prints -> > a message like this: +> > Cuando hay un conflicto en una imagen u otro archivo binario, git imprime +> > un mensaje así: > > > > ~~~ > > $ git pull origin master @@ -414,20 +415,21 @@ Conflicts can also be minimized with project management strategies: > > ~~~ > > {: .output} > > -> > The conflict message here is mostly the same as it was for `mars.txt`, but -> > there is one key additional line: +> > El mensaje informando el conflicto es básicamente el mismo que se imprimió para `mars.txt`, pero +> > hay una línea adicional: > > > > ~~~ > > warning: Cannot merge binary files: mars.jpg (HEAD vs. 439dc8c08869c342438f6dc4a2b615b05b93c76e) > > ~~~ -> > -> > Git cannot automatically insert conflict markers into an image as it does -> > for text files. So, instead of editing the image file, we must check out -> > the version we want to keep. Then we can add and commit this version. -> > -> > On the key line above, Git has conveniently given us commit identifiers -> > for the two versions of `mars.jpg`. Our version is `HEAD`, and Wolfman's -> > version is `439dc8c0...`. If we want to use our version, we can use +> > {: .output} +> > +> > Git no puede insertar indicadores de conflicto en una imagen como sí lo hace en los +> > archivos de texto. Por lo tanto, en vez de editar la imagen, debemos revisar la versión que +> > queremos mantener. Luego podemos agregar y hacer **commit** a esta versión. +> > +> > En la línea agregada de arriba, Git convenientemente nos dió identificadores de **commit** +> > para las dos versiones de `mars.jpg`. Nuestra version es `HEAD`, y la de Wolfman +> > es `439dc8c0...`. Si queremos usar nuestra versión, podemos usar > > `git checkout`: > > > > ~~~ @@ -442,8 +444,8 @@ Conflicts can also be minimized with project management strategies: > > ~~~ > > {: .output} > > -> > If instead we want to use Wolfman's version, we can use `git checkout` with -> > Wolfman's commit identifier, `439dc8c0`: +> > En cambio si queremos usar la versión de Wolfman, podemos usar `git checkout` con +> > el identificador de **commit** de Wolfman, `439dc8c0`: > > > > ~~~ > > $ git checkout 439dc8c0 mars.jpg @@ -457,10 +459,9 @@ Conflicts can also be minimized with project management strategies: > > ~~~ > > {: .output} > > -> > We can also keep *both* images. The catch is that we cannot keep them -> > under the same name. But, we can check out each version in succession -> > and *rename* it, then add the renamed versions. First, check out each -> > image and rename it: +> > También podemos mantener *ambas* imágenes. La clave es que no podemos mantenerlos con el mismo +> > nombre. Pero podemos mirar cada versión de forma sucesiva y *renombrarla*, y luego agregar las versiones renombradas. +> > Primero, revisar cada imagen y renombrarla: > > > > ~~~ > > $ git checkout HEAD mars.jpg @@ -470,7 +471,7 @@ Conflicts can also be minimized with project management strategies: > > ~~~ > > {: .bash} > > -> > Then, remove the old `mars.jpg` and add the two new files: +> > Luego, eliminar la vieja imagen `mars.jpg` y agregar los dos archivos nuevos: > > > > ~~~ > > $ git rm mars.jpg @@ -488,49 +489,51 @@ Conflicts can also be minimized with project management strategies: > > ~~~ > > {: .output} > > -> > Now both images of Mars are checked into the repository, and `mars.jpg` -> > no longer exists. +> > Ahora ambas imágenes de Marte estan ingresadas en el repositorio, y `mars.jpg` +> > ya no existe. > {: .solution} {: .challenge} -> ## A Typical Work Session + +> ## Una típica sesión de trabajo +> +> Te sientas en tu computadora para trabajar en un proyecto compartido que es mantenido en un +> repositorio Git remoto. Durante tu sesión de trabajo, realizas las siguientes acciones, +> pero no en éste orden: > -> You sit down at your computer to work on a shared project that is tracked in a -> remote Git repository. During your work session, you take the following -> actions, but not in this order: > -> - *Make changes* by appending the number `100` to a text file `numbers.txt` -> - *Update remote* repository to match the local repository -> - *Celebrate* your success with beer(s) -> - *Update local* repository to match the remote repository -> - *Stage changes* to be committed -> - *Commit changes* to the local repository +> - *Hacer cambios* agregando el número `100` al archivo de texto `numbers.txt` +> - *Actualizar repositorio remoto* para actualizar el repositorio local +> - *Celebrar* tu éxito con cerveza(s) +> - *Actualizar repositorio local* para actualizar el repositorio remoto +> - *Realizar cambios* con los cuales voy a hacer commit +> - *Hacer commit a los cambios* al repositorio local > -> In what order should you perform these actions to minimize the chances of -> conflicts? Put the commands above in order in the *action* column of the table -> below. When you have the order right, see if you can write the corresponding -> commands in the *command* column. A few steps are populated to get you -> started. +> ¿En qué orden deberías hacer estas acciones para minimizar la posibilidad de conflictos? +> Pon los comandos de arriba en orden en la columna *acción* de la tabla de abajo. +> Cuando tengas el orden correcto, ve si puedes escribir los comandos correspondientes en la columna +> *comando*. Algunos campos ya están completados para ayudarte a +> comenzar. > -> |order|action . . . . . . . . . . |command . . . . . . . . . . | +> |orden|acción . . . . . . . . . . |comando . . . . . . . . . . | > |-----|---------------------------|----------------------------| > |1 | | | > |2 | | `echo 100 >> numbers.txt` | > |3 | | | > |4 | | | > |5 | | | -> |6 | Celebrate! | `AFK` | +> |6 | ¡Celebrar! | `AFK` | > -> > ## Solution +> > ## Solución > > -> > |order|action . . . . . . |command . . . . . . . . . . . . . . . . . . . | +> > |orden|acción . . . . . . . . . . |comando . . . . . . . . . . | > > |-----|-------------------|----------------------------------------------| -> > |1 | Update local | `git pull origin master` | -> > |2 | Make changes | `echo 100 >> numbers.txt` | -> > |3 | Stage changes | `git add numbers.txt` | -> > |4 | Commit changes | `git commit -m "Add 100 to numbers.txt"` | -> > |5 | Update remote | `git push origin master` | -> > |6 | Celebrate! | `AFK` | +> > |1 | Actualizar repositorio local | `git pull origin master` | +> > |2 | Hacer cambios | `echo 100 >> numbers.txt` | +> > |3 | Realizar cambios | `git add numbers.txt` | +> > |4 | Hacer commit a los cambios | `git commit -m "Agregar 100 a numbers.txt"` | +> > |5 | Actualizar repositorio remoto | `git push origin master` | +> > |6 | ¡Celebrar! | `AFK` | > > > {: .solution} {: .challenge} diff --git a/_episodes/10-open.md b/_episodes/10-open.md index 2ca95bbdb6..b74c2310f7 100644 --- a/_episodes/10-open.md +++ b/_episodes/10-open.md @@ -1,133 +1,71 @@ --- -title: Open Science +title: Ciencia abierta teaching: 5 exercises: 5 questions: -- "How can version control help me make my work more open?" +- "¿Cómo un control de versiones me puede ayudar a tener mi trabajo más abierto?" objectives: -- "Explain how a version control system can be leveraged as an electronic lab notebook for computational work." +- "Explica como el control de versiones nos ayuda a tener un cuaderno de notas electrónico para todo nuestro trabajo computacional." keypoints: -- "Open scientific work is more useful and more highly cited than closed." +- "Trabajo científico abierto es más útil y puede ser más citado que si no lo es." --- -> The opposite of "open" isn't "closed". -> The opposite of "open" is "broken". +> Lo opuesto a "abierto" no es "cerrado". +> Lo opuesto a "abierto" es "quebrado". > -> --- John Wilbanks -{: .quotation} +>--- John Wilbanks -Free sharing of information might be the ideal in science, -but the reality is often more complicated. -Normal practice today looks something like this: +El libre intercambio de información podría ser el ideal en Ciencia. Pero la realidad, a menudo, es mucho más complicada. +En la práctica cotidiana vemos situaciones como la siguiente: -* A scientist collects some data and stores it on a machine - that is occasionally backed up by her department. -* She then writes or modifies a few small programs - (which also reside on her machine) - to analyze that data. -* Once she has some results, - she writes them up and submits her paper. - She might include her data—a growing number of journals require this—but - she probably doesn't include her code. -* Time passes. -* The journal sends her reviews written anonymously by a handful of other people in her field. - She revises her paper to satisfy them, - during which time she might also modify the scripts she wrote earlier, - and resubmits. -* More time passes. -* The paper is eventually published. - It might include a link to an online copy of her data, - but the paper itself will be behind a paywall: - only people who have personal or institutional access - will be able to read it. +* Una científica recoge algunos datos y los almacena en una máquina que seguramente tiene en su oficina. +* Luego ella escribe y modifica unos pocos programas para analizar los datos (los cuales residen en su computadora). +* Una vez que tiene algunos resultados, ella escribe y presenta su artículo. Podría incluir sus datos -en varias revistas que los requieran- pero probablemente no incluya su código. +* El tiempo pasa. +* La revista envía las revisiones de un puñado de personas anónimas que trabajan en su campo de actividad. + Ella revisa su artículo para satisfacer las revisiones propuestas. Durante ese tiempo ella también podría modificar los **scripts** que escribió anteriormente,y vuelve a enviar. +* Pasa más tiempo. +* El artículo finalmente se publica. +Se podría incluir un enlace a una copia online de sus datos, pero el mismo artículo está detrás de un sito web de pago: sólo las personas que tienen acceso personal o institucional serán capaces de leerlo. -For a growing number of scientists, -though, -the process looks like this: +Para otros muchos científicos, el proceso se ve así: -* The data that the scientist collects is stored in an open access repository - like [figshare](http://figshare.com/) or - [Zenodo](http://zenodo.org), possibly as soon as it's collected, - and given its own - [Digital Object Identifier](https://en.wikipedia.org/wiki/Digital_object_identifier) (DOI). - Or the data was already published and is stored in - [Dryad](http://datadryad.org/). -* The scientist creates a new repository on GitHub to hold her work. -* As she does her analysis, - she pushes changes to her scripts - (and possibly some output files) - to that repository. - She also uses the repository for her paper; - that repository is then the hub for collaboration with her colleagues. -* When she's happy with the state of her paper, - she posts a version to [arXiv](http://arxiv.org/) - or some other preprint server - to invite feedback from peers. -* Based on that feedback, - she may post several revisions - before finally submitting her paper to a journal. -* The published paper includes links to her preprint - and to her code and data repositories, - which makes it much easier for other scientists - to use her work as starting point for their own research. +* Los datos que obtiene son almacenados, tan pronto como los colecta, en un repositorio de acceso abierto, como puede ser [figshare](http://figshare.com/) o [Zenodo](http://zenodo.org), obteniendo su propio [Digital Object Identifier] (https://en.wikipedia.org/wiki/Digital_object_identifier) (DOI). O los datos que han sido recientemente publicados, son almacenados en [Dryad](http://datadryad.org/). +* La científica crea un nuevo repositorio en GitHub para guardar su trabajo. +* Al hacer su análisis de los datos, guarda los cambios de sus **scripts** (y posiblemente algunos archivos de salida) en ese repositorio. También utiliza el repositorio para su artículo. Entonces ese repositorio es el centro de colaboración con sus colegas. +* Cuando está satisfecha con el estado de su artículo, publica una versión en [arXiv](http://arxiv.org/) o en algún otro servidor de preimpresión para invitar a sus compañeros a una retroalimentación. +* Basado en esa retroalimentación, puede escribir varias revisiones antes de enviar finalmente su artículo a la revista. +* El artículo publicado incluye enlaces a su preimpresión y a sus repositorios de código y datos, lo que hace mucho más fácil para otros científicos utilizar este trabajo como punto de partida para su propia investigación. -This open model accelerates discovery: -the more open work is, -[the more widely it is cited and re-used](http://dx.doi.org/10.1371/journal.pone.0000308). -However, -people who want to work this way need to make some decisions -about what exactly "open" means and how to do it. You can find more on the different aspects of Open Science in [this book](http://link.springer.com/book/10.1007/978-3-319-00026-8). +Este modelo abierto acelera la investigación: el trabajo abierto [se cita y se reutiliza](http://dx.doi.org/10.1371/journal.pone.0000308). Sin embargo, las personas que quieren trabajar de esta manera necesitan tomar algunas decisiones sobre qué significa exactamente "abierto" y cómo hacerlo. Puedes encontrar más información sobre los diferentes aspectos de la Ciencia Abierta en [el libro](http://link.springer.com/book/10.1007/978-3-319-00026-8). -This is one of the (many) reasons we teach version control. -When used diligently, -it answers the "how" question -by acting as a shareable electronic lab notebook for computational work: +Ésta es una de las muchas razones por las que enseñamos el control de versiones. Cuando se utiliza con diligencia, responde a "cómo" actúa un cuaderno de laboratorio electrónico compartible: -* The conceptual stages of your work are documented, including who did - what and when. Every step is stamped with an identifier (the commit ID) - that is for most intents and purposes unique. -* You can tie documentation of rationale, ideas, and other - intellectual work directly to the changes that spring from them. -* You can refer to what you used in your research to obtain your - computational results in a way that is unique and recoverable. -* With a distributed version control system such as Git, the version - control repository is easy to archive for perpetuity, and contains - the entire history. +* Las etapas conceptuales del trabajo están documentadas, qué y cuándo. Cada paso está marcado con un identificador (el ID de confirmación) de cada uno de los intentos y propósitos. +* Puedes vincular tu documentación de ideas y otros trabajos intelectuales directamente con los cambios que surgen de ellos. +* Puedes referirte a lo que utilizaste en tu investigación para obtener tus resultados computacionales de manera única y recuperable. +* Con un sistema de control de versiones distribuido como Git, la versión del repositorio de control es fácil de archivar a perpetuidad y contiene toda la historia. -> ## Making Code Citable +> ## Haciendo código citable > -> [This short guide](https://guides.github.com/activities/citable-code/) from GitHub -> explains how to create a Digital Object Identifier (DOI) for your code, -> your papers, -> or anything else hosted in a version control repository. +> [Esta breve guía](https://guides.github.com/activities/citable-code/) de GitHub +> explica cómo crear un "Digital Object Identifier (DOI)" para tu código, tus artículos, o cualquier cosa alojada en un repositorio de control de versiones. {: .callout} -> ## How Reproducible Is My Work? +> ## ¿Cuán reproducible es mi trabajo? > -> Ask one of your labmates to reproduce a result you recently obtained -> using only what they can find in your papers or on the web. -> Try to do the same for one of their results, -> then try to do it for a result from a lab you work with. +> Pide a uno de tus compañeros de laboratorio que reproduzca un resultado que obtuviste recientemente +> utilizando sólo lo que ellos puedan encontrar en tus artículos o en la web. +> Trata de hacer lo mismo para uno de sus resultados, +> luego trata de hacerlo para obtener un resultado de un laboratorio con el que trabajas. {: .challenge} -> ## How to Find an Appropriate Data Repository? +> ## ¿Cómo encontrar un repositorio de datos adecuado? > -> Surf the internet for a couple of minutes and check out the data repositories -> mentioned above: [Figshare](http://figshare.com/), [Zenodo](http://zenodo.org), -> [Dryad](http://datadryad.org/). Depending on your field of research, you might -> find community-recognized repositories that are well-known in your field. -> You might also find useful [these data repositories recommended by Nature]( -> http://www.nature.com/sdata/data-policies/repositories). -> Discuss with your neighbor which data repository you might want to -> approach for your current project and explain why. +> Navega por Internet durante un par de minutos y echa un vistazo a los repositorios de datos mencionado anteriormente: [Figshare](http://figshare.com/), [Zenodo](http://zenodo.org), [Dryad](http://datadryad.org/). Dependiendo de tu campo de investigación, encuentra repositorios reconocidos por la comunidad en tu campo. También puede ser útil [estos repositorios de datos recomendados por Nature](http://www.nature.com/sdata/data-policies/repositories). Discute con tu vecino qué repositorio de datos deseas abordar para tu proyecto actual y explicale por qué. {: .challenge} -> ## Can I Also Publish Code? +> ## ¿Puedo también publicar código? > -> There are many new ways to publish code and to make it citable. One -> way is described [on the homepage of GitHub itself]( -> https://guides.github.com/activities/citable-code/). -> Basically it's a combination of GitHub (where the code is) and Zenodo (the -> repository creating the DOI). Read through this page while being aware -> that this is only one of many ways to making your code citable. +> Hay nuevas maneras de publicar código y hacer que sea citable. Uno de ellos se describe [en la página principal del mismo GitHub](https://guides.github.com/activities/citable-code/). Básicamente es una combinación de GitHub (donde está el código) y Zenodo (el repositorio que crea el DOI). Lee esta página mientras sabes que ésta es sólo una de las muchas maneras de hacer tu código citable. {: .challenge} diff --git a/_episodes/11-licensing.md b/_episodes/11-licensing.md index 5bfa49dbf4..7e662c7760 100644 --- a/_episodes/11-licensing.md +++ b/_episodes/11-licensing.md @@ -1,80 +1,48 @@ --- -title: Licensing +title: Licencia teaching: 5 exercises: 0 questions: -- "What licensing information should I include with my work?" +- "¿Qué información sobre licencias debería incluir en mi trabajo?" objectives: -- "Explain why adding licensing information to a repository is important." -- "Choose a proper license." -- "Explain differences in licensing and social expectations." +- "Explicar la importancia de agregar información de licencias a nuestro trabajo." +- "Escoger la licencia apropiada." +- "Explicar las diferencias en licencias y algunas expectativas sociales." keypoints: -- "People who incorporate GPL'd software into their own software must make their software also open under the GPL license; most other open licenses do not require this." -- "The Creative Commons family of licenses allow people to mix and match requirements and restrictions on attribution, creation of derivative works, further sharing, and commercialization." -- "People who are not lawyers should not try to write licenses from scratch." +- "Las personas que usan la licencia **GPL** en su software tienen que asegurarse de que toda la estructura esté bajo ésta licencia; muchas otras licencias no requieren esto." +- La familia de licencias **Creative Commons** permite a las personas adaptarse a varios requerimientos y restricciones de atribución, la creación de trabajo derivado, compartir el trabajo, y comercialización." +- "Personas sin conocimientos de leyes no deberían tratar de escribir nuevas licencias desde cero." --- -When a repository with source code, a manuscript or other creative -works becomes public, it should include a file `LICENSE` or -`LICENSE.txt` in the base directory of the repository that clearly -states under which license the content is being made available. This -is because creative works are automatically eligible for intellectual -property (and thus copyright) protection. Reusing creative works -without a license is dangerous, because the copyright holders could -sue you for copyright infringement. +Cuando un repositorio público contiene código fuente, un manuscrito u otro trabajo creativo, éste debe incluir un archivo con el nombre `LICENCIA` o `LICENCIA.txt` en el directorio base del repositorio, que indique claramente bajo que licencia se pone a disposición el contenido. Esto se debe, a que se aplica automáticamente a las obras creativas la protección de propiedad intelectual (y por lo tanto derechos de autor). La reutilización de trabajos creativos sin licencia es peligrosa, ya que los titulares de los derechos de autor podrían realiza una demanda por infringir la misma. -A license solves this problem by granting rights to others (the -licensees) that they would otherwise not have. What rights are being -granted under which conditions differs, often only slightly, from one -license to another. In practice, a few licenses are by far the most -popular, and [choosealicense.com](http://choosealicense.com/) will -help you find a common license that suits your needs. Important -considerations include: +Una licencia resuelve el problema otorgando derechos a otros (los licenciatarios) que de otro modo no tendrían. ¿Qué derechos se otorgan bajo qué condiciones difieren, a menudo de forma leve, de una licencia a otra? En la práctica, algunas licencias son las más populares, y [choosealicense.com](http://choosealicense.com/) te ayudará a encontrar una licencia que se adapte a tus necesidades. Las consideraciones importantes incluyen: -* Whether you want to address patent rights. -* Whether you require people distributing derivative works to also - distribute their source code. -* Whether the content you are licensing is source code. -* Whether you want to license the code at all. +* Si deseas abordar los derechos de patente. +* Si necesitas personas que distribuyan los trabajos derivados de tu código fuente. +* Si el contenido que estás otorgando es la licencia del código fuente. +* Si deseas licenciar todo el código. -Choosing a licence that is in common use makes life easier for -contributors and users, because they are more likely to already be -familiar with the license and don't have to wade through a bunch of -jargon to decide if they're ok with it. The [Open Source -Inititative](http://opensource.org/licenses) and [Free Software -Foundation](http://www.gnu.org/licenses/license-list.html) both -maintain lists of licenses which are good choices. +Elegir una licencia que sea de uso común hace la vida más fácil para los contribuyentes y los usuarios, porque es probable que ya estén familiarizados con la licencia y no tengan que sortear una jerga específica para decidir si está bien. +La [Iniciativa Open Source](http://opensource.org/licenses) y [Free Software Foundation](http://www.gnu.org/licenses/license-list.html) mantienen listas de licencias que pueden ser buenas elecciones. -[This article][software-licensing] provides an excellent overview of -licensing and licensing options from the perspective of scientists who -also write code. +Este artículo [licencia de software](http://journals.plos.org/ploscompbiol/article?id=10.1371/journal.pcbi.10h02598) proporciona una excelente descripción de licencias y de opciones de licencias desde la perspectiva de los científicos que escriben código. -At the end of the day what matters is that there is a clear statement -as to what the license is. Also, the license is best chosen from the -get-go, even if for a repository that is not public. Pushing off the -decision only makes it more complicated later, because each time a new -collaborator starts contributing, they, too, hold copyright and will -thus need to be asked for approval once a license is chosen. +Al final del día lo que importa es que haya un informe claro sobre cuál es la licencia. Es mejor elegir la licencia desde el principio, incluso si se trata de un repositorio que no es público. Retrasar la decisión de elección, solo hace más complicado en adelante, porque cada vez que un nuevo colaborador comienza a contribuir, ellos también tienen derechos de autor y, por lo tanto, se les debe pedir aprobación una vez que se elige una licencia. -> ## Can I Use Open License? +> ## ¿Puedes usar **Open License**? > -> Find out whether you are allowed to apply an open license to your software. -> Can you do this unilaterally, -> or do you need permission from someone in your institution? -> If so, who? +> Investiga si puedes usar una **Open license** o "Licencia Abierta" en tu **software**. ¿Puedes hacer eso por tí mismo?, ¿o necesitas permiso de alguien dentro de tu institución? Si necesitas permiso, ¿de quién? {: .challenge} -> ## What licenses have I already accepted? +> ## ¿Qué licencias ya he aceptado? > -> Many of the software tools we use on a daily basis (including in this workshop) are -> released as open-source software. Pick a project on GitHub from the list below, or -> one of your own choosing. Find its license (usually in a file called `LICENSE` or -> `COPYING`) and talk about how it restricts your use of the software. Is it one of -> the licenses discussed in this session? How is it different? -> - [Git](https://github.com/git/git), the source-code management tool -> - [CPython](https://github.com/python/cpython), the standard implementation of the Python language -> - [Jupyter](https://github.com/jupyter), the project behind the web-based Python notebooks we'll be using -> - [EtherPad](https://github.com/ether/etherpad-lite), a real-time collaborative editor +> Muchas herramientas de **software** que usamos día a día (incluyendo las herramientas en este **workshop**) son +> **open-source software**. Escoge uno de los proyectos de GitHub de la lista de abajo, o algún otro que te interese. Encuentra la licencia (usualmente es un archivo que se llama `LICENSE` o `COPYING`) y luego habla con tus compañeros sobre como ésta licencia te permite o te restringe el uso del **software**. ¿Es una de las licencias que hemos visto en esta sesión? ¿Qué tan diferente es ésta licencia? +> - [Git](https://github.com/git/git), herramientas para el manejo de código fuente. +> - [CPython](https://github.com/python/cpython), implementación estándar del lenguaje Python. +> - [Jupyter](https://github.com/jupyter), proyectos web en Python para **notebooks**. +> - [EtherPad](https://github.com/ether/etherpad-lite), un editor colaborativo en tiempo real. {: .challenge} -[software-licensing]: http://journals.plos.org/ploscompbiol/article?id=10.1371/journal.pcbi.1002598 + diff --git a/_episodes/12-citation.md b/_episodes/12-citation.md index 6060d86b25..190c2822e0 100644 --- a/_episodes/12-citation.md +++ b/_episodes/12-citation.md @@ -1,20 +1,19 @@ --- -title: Citation +title: Citas teaching: 2 exercises: 0 questions: -- "How can I make my work easier to cite?" +- "¿Cómo puedo hacer que mi trabajo sea más fácil de citar?" objectives: -- "Make your work easy to cite" +- "Haz que tu trabajo sea más fácil de citar" keypoints: -- "Add a CITATION file to a repository to explain how you want your work cited." +- "Agrega un archivo CITATION a el repositorio y explica cómo quieres que tu trabajo sea citado." --- -You may want to include a file called `CITATION` or `CITATION.txt` -that describes how to reference your project; -the [one for Software -Carpentry](https://github.com/swcarpentry/website/blob/gh-pages/CITATION) -states: +Puedes incluir un archivo llamado `CITATION` o `CITATION.txt` +que describa cómo referenciar tu proyecto; +el siguiente es el de +[Software Carpentry](https://github.com/swcarpentry/website/blob/gh-pages/CITATION): ~~~ To reference Software Carpentry in publications, please cite both of the following: diff --git a/_episodes/13-hosting.md b/_episodes/13-hosting.md index cf4033763c..f6c364897e 100644 --- a/_episodes/13-hosting.md +++ b/_episodes/13-hosting.md @@ -1,82 +1,85 @@ --- -title: Hosting +title: Hospedaje teaching: 10 exercises: 0 questions: -- "Where should I host my version control repositories?" +- "¿Dónde debería alojar mis repositorios de control de versiones?" objectives: -- "Explain different options for hosting scientific work." +- "Explicar diferentes opciones para realizar trabajos científicos." keypoints: -- "Projects can be hosted on university servers, on personal domains, or on public forges." -- "Rules regarding intellectual property and storage of sensitive information apply no matter where code and data are hosted." +- "Los proyectos pueden alojarse en servidores de la universidad, en dominios personales o públicas." +- "Las reglas con respecto a la propiedad intelectual y el almacenamiento de información confidencial se aplican sin importar dónde se alojan el código y los datos." --- -The second big question for groups that want to open up their work is where to -host their code and data. One option is for the lab, the department, or the -university to provide a server, manage accounts and backups, and so on. The -main benefit of this is that it clarifies who owns what, which is particularly -important if any of the material is sensitive (i.e., relates to experiments -involving human subjects or may be used in a patent application). The main -drawbacks are the cost of providing the service and its longevity: a scientist -who has spent ten years collecting data would like to be sure that data will -still be available ten years from now, but that's well beyond the lifespan of -most of the grants that fund academic infrastructure. +La segunda gran pregunta para los grupos que quieren liberar su trabajo es dónde +hospedar su código y datos. Una opción es que el laboratorio, departamento o la +universidad provean un servidor, gestionen cuentas y respaldos, etc. El principal +beneficio de esto es que clarifica quién es dueño de qué, lo cual es particularmente +importante si algún material es sensible (es decir, se relaciona a experimentos +que involucran sujetos humanos o pueden ser usados en una patente). Las principales +desventajas son el costo de proveer el servicio y su longevidad: un científico +que ha pasado diez años colectando datos quisiera asegurarse de que estos estarán +disponibles en diez años más, pero eso está más allá del tiempo de vida de muchos +de los subsidios que financian la infraestructura académica. -Another option is to purchase a domain and pay an Internet service provider -(ISP) to host it. This gives the individual or group more control, and -sidesteps problems that can arise when moving from one institution to another, -but requires more time and effort to set up than either the option above or the -option below. +Otra opción es comprar un dominio y pagar a un Proveedor de Servicios de Internet +(ISP por sus siglas en inglés) para hospedarlo. Esto da al individuo o grupo mayor +control, y le da la vuelta a problemas que pueden surgir cuando se cambien de una +institución a otra, pero requiere más tiempo y esfuerzo para configurar que la +opción anterior o siguiente. -The third option is to use a public hosting service like +La tercera opción es utilizar un servicio de hospedaje público como [GitHub](http://github.com), [GitLab](http://gitlab.com), -[BitBucket](http://bitbucket.org), or [SourceForge](http://sourceforge.net). -Each of these services provides a web interface that enables people to create, -view, and edit their code repositories. These services also provide -communication and project management tools including issue tracking, wiki pages, -email notifications, and code reviews. These services benefit from economies of -scale and network effects: it's easier to run one large service well than to run -many smaller services to the same standard. It's also easier for people to -collaborate. Using a popular service can help connect your project with -communities already using the same service. +[BitBucket](http://bitbucket.org) o [SourceForge](http://sourceforge.net). +Cada uno de estos servicios provee una interfaz web que permite a las personas +crear, ver y editar sus repositorios de código. Estos servicios también proveen +herramientas de comunicación y gestión de proyectos que incluyen `seguimiento de problemas`, +páginas wiki, notificaciones de correo electrónico y revisiones de código. Estos +servicios se benefician de economías de escalamiento y efectos de redes: es más +fácil correr un servicio grande bien que correr varios pequeños servicios al +mismo estándar. También es más fácil para la gente colaborar. Usando un servicio +popular puede ayudar a conectar tu proyecto con una comunidad que ya está usando el +mismo servicio. -As an example, Software Carpentry [is on -GitHub]({{ swc_github }}) where you can find the [source for this -page]({{page.root}}/_episodes/13-hosting.md). -Anyone with a GitHub account can suggest changes to this text. +Como un ejemplo, Software Carpentry [está en +GitHub]({{ swc_github }}), donde puedes encontrar el [código fuente para esta +página]({{page.root}}/_episodes/13-hosting.md). +Cualquiera con una cuenta de GitHub puede sugerir cambios a este texto. -Using large, well-established services can also help you quickly take advantage -of powerful tools. One such tool, continuous integration (CI), can -automatically run software builds and tests whenever code is committed or pull -requests are submitted. Direct integration of CI with an online hosting service -means this information is present in any pull request, and helps maintain code -integrity and quality standards. While CI is still available in self-hosted -situations, there is much less setup and maintenance involved with using an -online service. Furthermore, such tools are often provided free of charge to -open source projects, and are also available for private repositories for a fee. +Usando servicios grandes y bien establecidos puede también ayudarte a tomar +ventaja rápidamente de herramientas poderosas tales como la Integración +Continua (CI por sus siglas en inglés). CI puede automaticamente construir el ejecutable a partir del codigo fuente y probar el +software automáticamente cada vez que se hace un `commit` o se somete un +`pull request`. La integración directa de CI con un servicio de hospedaje en +línea significa que esta información está presente en cualquier `pull request` +y ayudar a mantener la integridad y estándares de calidad del código. Si bien +CI está disponible en situaciones de auto-hospedaje, hay menos configuración y +mantenimiento al usar un servicio en línea. Más aún, estas herramientas son +proporcionadas sin costo alguno para proyectos de código abierto y están también +disponibles para repositorios privados por una cuota. -> ## Institutional Barriers +> ## Barreras Institucionales > -> Sharing is the ideal for science, -> but many institutions place restrictions on sharing, -> for example to protect potentially patentable intellectual property. -> If you encounter such restrictions, -> it can be productive to inquire about the underlying motivations -> either to request an exception for a specific project or domain, -> or to push more broadly for institutional reform to support more open science. +> Compartir es el ideal de la ciencia, +> pero muchas instituciones imponen restricciones al compartir, +> por ejemplo para proteger propiedad intelectual potencialmente patentable. +> Si encuentras tales restricciones, +> pudiera ser productivo indagar acerca de las motivaciones +> ya sea para solicitar una excepción para un proyecto específico o dominio, +> o para impulsar una reforma institucional más amplia para el apoyo de la ciencia abierta. {: .callout} -> ## Can My Work Be Public? +> ## ¿Mi Trabajo Puede Ser Público? > -> Find out whether you are allowed to host your work openly on a public forge. -> Can you do this unilaterally, -> or do you need permission from someone in your institution? -> If so, who? +> Averigua si tienes permitido hospedar tu trabajo abiertamente en un repositorio público. +> ¿Puedes hacer esto unilateralmente, +> o necesitas permiso de alguien en tu institución? +> Si ese es el caso, ¿de quién? {: .challenge} -> ## Where Can I Share My Work? +> ## ¿Dónde Puedo Compartir Mi Trabajo? > -> Does your institution have a repository or repositories that you can -> use to share your papers, data and software? How do institutional repositories -> differ from services like [arXiV](http://arxiv.org/), [figshare](http://figshare.com/) and [GitHub](http://github.com/)? +> ¿Tu institución tiene un repositorio(s) donde puedas compartir tus +> artículos, datos y software? ¿Cómo los repositorios institucionales +> difieren de servicios como [arXiV](http://arxiv.org/), [figshare](http://figshare.com/) y [GitHub](http://github.com/)? {: .challenge} diff --git a/_episodes/14-supplemental-rstudio.md b/_episodes/14-supplemental-rstudio.md index 36ce344a11..4cbbecc0e1 100644 --- a/_episodes/14-supplemental-rstudio.md +++ b/_episodes/14-supplemental-rstudio.md @@ -1,103 +1,89 @@ --- -title: Using Git from RStudio +title: Usando Git desde RStudio teaching: 10 exercises: 0 questions: -- "How can I use Git with RStudio?" +- "¿Cómo puedo usar Git desde RStudio?" objectives: -- "Understand how to use Git from RStudio." +- "Entender cómo usar Git desde RStudio." keypoints: -- "Create an RStudio project" +- "Crear un proyecto en RStudio" --- -Since version control is so useful when developing scripts, RStudio has built-in -integration with Git. There are some more obscure Git features that you still -need to use the command-line for, but RStudio has a nice interface for most -common operations. +El uso de control de versiones es muy útil cuando escribimos **scripts**, por eso RStudio puede usarse con Git. Hay algunas funcionalidades de Git que solamente se pueden usar desde la terminal, pero RStudio nos da una rica interfaz de trabajo para realizar las operaciones más habituales de control de versiones. -RStudio let's you create a [project][rstudio-projects] associated with -a given directory. This is a way to keep track of related files. One -of the way to keep track of them is via version control! To get -started using RStudio for version control, let's make a new project: +RStudio te permite crear un proyecto [project][rstudio-projects] asociado a un directorio determinado. Esta es una manera de mantenerse al tanto de los archivos asociados al proyecto. Una manera de tener control de archivos es mediante el uso de un programa de control de versiones. Para empezar a usar RStudio para el control de versiones, comencemos por crear un nuevo proyecto: ![](../fig/RStudio_screenshot_newproject.png) -This will pop up a window asking us how we want to create the project. We have -some options here. Let's say that we want to use RStudio with the planets -repository that we already made. Since that repository lives in a directory on -our computer, we'll choose "existing directory": +Una nueva ventana se abrirá y preguntará cómo queremos crear el proyecto. Tenemos +aquí varias opciones. Supongamos que queremos usar RStudio con el repositorio de planetas +que ya hemos creado. Como ese repositorio ya está en una carpeta en tu computadora, +podemos escoger la opción "Existing Directory": ![](../fig/RStudio_screenshot_existingdirectory.png) -> ## Do You See a "Version Control" Option? +> ## ¿Puedes ver la opción de "Version Control"? > -> Although we're not going to use it here, there should be a "version control" -> option on this menu. That is what you would click on if you wanted to -> create a project on your computer by cloning a repository from github. -> If that option is not present, it probably means that RStudio doesn't know -> where your Git executable is. See -> [this page](https://stat545-ubc.github.io/git03_rstudio-meet-git.html) -> for some debugging advice. Even if you have Git installed, you may need -> to accept the XCode license if you are using MacOSX. +> Aunque no vamos a usar ésta opción aquí, deberías poder ver una opción en el menú que diga +> "Version Control". Esta es la opción que debes escoger cuando quieras crear +> un proyecto en tu computadora mediante una clonación de un repositorio de GitHub. +> Si esta opción no es visible, probablemente significa que RStudio no sabe +> donde está tu ejecutable de Git. Mira +> [esta página](https://stat545-ubc.github.io/git03_rstudio-meet-git.html) +> para encontrar algunos consejos. Incluso después de instalar Git, si estás usando MacOSX +> algunas veces puede ser necesario que tengas que aceptar la licencia de XCode {: .callout} -Next, RStudio will ask which existing directory we want to use. Click "browse" -to navigate to the correct directory on your computer, then click "create -project": +En el siguiente paso, RStudio va a preguntar cuál es la carpeta existente que queremos usar. Haremos +click en el navegador de archivos para navegar a la carpeta correcta en tu computadora, y luego haremos click en +"Create Project": ![](../fig/RStudio_screenshot_navigateexisting.png) -Ta-da! Now you have an R project containing your repository. Notice the -vertical "Git" menu that is now on the menu bar. This means RStudio has -recognized that this directory is a git repository, so it's giving you tools -to use Git: +¡Y ya está! Ahora tenemos un proyecto en R que contiene su propio repositorio. Fíjate que en el menú ahora aparece un botón con "Git" en letras verticales. Esto significa que RStudio ha reconocido que ésta carpeta es un repositorio de Git, así que te proporcionará las herramientas para usar Git: ![](../fig/RStudio_screenshot_afterclone.png) -To edit the files in your repository, you can click on them from the panel in -the lower right. Let's add some more information about Pluto: +Para editar los archivos en tu repositorio, puedes hacer click en el archivo desde el panel inferior izquierdo. Vamos a añadir más información sobre Plutón: ![](../fig/RStudio_screenshot_editfiles.png) -Once we have saved our edited files, we can also use RStudio to commit these changes. Go to the git menu and click -"commit": +Ahora que hemos guardado nuestros archivos, podemos usar RStudio para hacer permanentes los cambios. Usa el botón y haz clik a "Commit": ![](../fig/RStudio_screenshot_commit.png) -This will bring up a screen where you can select which files to commit (check -the boxes in the "staged" column) and enter a commit message (in the upper -right). The icons in the "status" column indicate the current status of each -file. You can also see the changes to each file by clicking on its name. Once -everything is the way you want it, click "commit": +Esto abrirá una ventana donde puedes seleccionar de qué archivos quieres hacer **commit** (marca +sus casillas en la columna "Staged") y luego escribe un mensaje para el **commit** (en el panel +superior derecho). Los iconos en la columna "Status" indican el estado actual de cada +archivo. También puedes ver los cambios de cada archivo haciendo click en su nombre. Una vez +que todo esté de la forma que quieres, haz click en "Commit": ![](../fig/RStudio_screenshot_review.png) -You can push these changes by selecting "push" from the Git menu. There are -also options there to pull from a remote version of the repository, and view -the history: +Puedes subir los cambios seleccionando "Push" en el menú de Git. Allí hay también +opciones para traernos cambios (hacer **push**) desde una versión remota de este repositorio, y ver +el historial de cambios realizados: ![](../fig/RStudio_screenshot_history.png) -> ## Are the Push/Pull Commands Grayed Out? +> ¿Están los comandos **Push** y **Pull** en gris? > -> If this is the case, it generally means that RStudio doesn't know the -> location of any other version of your repository (i.e. the one on GitHub). -> To fix this, open a terminal to the repository and enter the command: -> `git push -u origin master`. Then restart RStudio. +> Si este es el caso, generalmente significa que RStudio no sabe dónde están las +> otras versiones de tu repositorio (por ejemplo, en GitHub). +> Para solucionar esto, abre una terminal, sitúate en el repositorio y luego lanza el siguiente comando: +> `git push -u origin master`. Luego reinicia RStudio. {: .callout} -If we click on "history", we can see a pretty graphical version of what -`git log` would tell us: +Si hacemos click en el historial de cambios "History", podemos ver una versión gráfica de lo +que obtendríamos con el comando `git log`: ![](../fig/RStudio_screenshot_viewhistory.png) -RStudio creates some files that is uses to keep track of your project. You -generally don't want to track these, so adding them to your .gitignore file -is a good idea: +RStudio crea algunos archivos que le ayudan a mantener un control de los cambios en el proyecto. Normalmente no deseamos que Git los incluya en el control de versiones, así que es una buena idea agregar sus nombres al .gitignore: ![](../fig/RStudio_screenshot_gitignore.png) -There are many more features buried in the RStudio git interface, but these -should be enough to get you started! +Hay muchas más opciones que se pueden encontrar en la interfaz de RStudio, pero las que hemos visto son suficientes para comenzar. [rstudio-projects]: https://support.rstudio.com/hc/en-us/articles/200526207-Using-Projects diff --git a/_extras/discuss.md b/_extras/discuss.md index a2af29f8d2..4fddcfafa8 100644 --- a/_extras/discuss.md +++ b/_extras/discuss.md @@ -4,19 +4,19 @@ title: Discussion permalink: /discuss/ --- -## Frequently Asked Questions +## Preguntas frecuentes -People often have questions about Git beyond the scope of the core material. -Students who have completed the rest of the lessons might find value in looking through the following topics. +La gente a menudo tiene preguntas sobre Git más allá del alcance del material central. +Los estudiantes que han completado el resto de las lecciones pueden encontrar valor al examinar los siguientes temas. -Note that since this material isn't essential for basic Git usage, it won't be covered by the instructor. +Tenga en cuenta que dado que este material no es esencial para el uso básico de Git, no será cubierto por el instructor. -## More Advanced Git Configuration +## Más configuración avanzada de Git -In [Setting Up Git]({{ page.root }}/02-setup/), -we used `git config --global` to set some default options for Git. -It turns out that these configuration options get stored in your home directory -in a plain text file called `.gitconfig`. +En [Configuración de Git]({{page.root}}/02-setup/), +usamos `git config --global` para establecer algunas opciones predeterminadas para Git. +Resulta que estas opciones de configuración se almacenan en su directorio de inicio +en un archivo de texto sin formato llamado `.gitconfig`. ~~~ $ cat ~/.gitconfig @@ -34,53 +34,53 @@ $ cat ~/.gitconfig ~~~ {: .output} -This file can be opened in your preferred text editor. -(Note that it is recommended to continue using the `git config` command, -as this helps avoid introducing syntax errors.) +Este archivo se puede abrir en su editor de texto preferido. +(Tenga en cuenta que se recomienda continuar usando el comando `git config`, +ya que esto ayuda a evitar la introducción de errores de sintaxis). -Eventually, you will want to start customizing Git's behaviour. -This can be done by adding more entries to your `.gitconfig`. -The available options are described in the manual: +Eventualmente, querrás comenzar a personalizar el comportamiento de Git. +Esto se puede hacer agregando más entradas a su `.gitconfig`. +Las opciones disponibles se describen en el manual: ~~~ $ git config --help ~~~ {: .bash} -In particular, you might find it useful to add aliases. -These are like shortcuts for longer git commands. -For example, if you get sick of typing `git checkout` all the time, -you could run the command: +En particular, puede resultarle útil agregar alias. +Estos son como accesos directos para comandos de git más largos. +Por ejemplo, si te cansas de escribir `git checkout` todo el tiempo, +podrías ejecutar el comando: ~~~ $ git config --global alias.co checkout ~~~ {: .bash} -Now if we return to the example from [Exploring History]({{ page.root }}/05-history/) where we ran: +Ahora, si volvemos al ejemplo de [Explorando el historial]({{ page.root }}/05-history/) where we ran: ~~~ $ git checkout f22b25e mars.txt ~~~ {: .bash} -we could now instead type: +ahora podríamos escribir: ~~~ $ git co f22b25e mars.txt ~~~ {: .bash} -## Styling Git's Log +## Diseñando el registro de Git -A good target for customization is output from the log. -The default log is quite verbose but gives no graphical hints -such as information about which commits were done locally -and which were pulled from remotes. +Un buen objetivo para la personalización sale del registro. +El registro predeterminado es bastante detallado pero no da pistas gráficas +como información sobre qué confirmaciones se realizaron localmente +y que fueron sacados de controles remotos. -You can use `git log --help` and `git config --help` to look for different ways to change -the log output. -Try the following commands and see what effect they have: +Puede usar `git log --help` y` git config --help` para buscar diferentes formas de cambiar +la salida de registro. +Pruebe los siguientes comandos y vea qué efecto tienen: ~~~ $ git config --global alias.lg "log --graph" @@ -90,8 +90,8 @@ $ git lg ~~~ {: .bash} -If you don't like the effects, -you can undo them with: +Si no te gustan los efectos, +puedes deshacerlos con: ~~~ $ git config --global --unset alias.lg @@ -100,47 +100,47 @@ $ git config --global --unset format.pretty ~~~ {: .bash} -> ## Undoing Git Configuration Changes +> ## Deshacer cambios en la configuración de Git > -> You can use the `--unset` flag to delete unwanted options from `.gitconfig`. -> Another way to roll back changes is to store your `.gitconfig` using Git. +> Puede usar el indicador `--unset` para eliminar las opciones no deseadas de` .gitconfig`. +> Otra forma de deshacer los cambios es almacenar su `.gitconfig` usando Git. > -> For hints on what you might want to configure, -> go to GitHub and search for "gitconfig". -> You will find hundreds of repositories in which people have stored -> their own Git configuration files. -> Sort them by the number of stars and have a look at the top few. -> If you find some you like, -> please check that they're covered by an open source license before you clone them. +> Para sugerencias sobre lo que puede querer configurar, +> vaya a GitHub y busque "gitconfig". +> Encontrará cientos de repositorios en los que las personas han almacenado +> sus propios archivos de configuración de Git. +> Ordenarlos por el número de estrellas y echar un vistazo a los mejores. +> Si encuentras alguno que te guste, +> compruebe que estén cubiertos por una licencia de código abierto antes de clonarlos. {: .callout} -## Non-text Files +## Archivos sin texto -Recall when we discussed [Conflicts]({{ page.root }}/09-conflict/) -there was a challenge that asked, -"What does Git do -when there is a conflict in an image or some other non-textual file -that is stored in version control?" +Recordar cuando discutimos [Conflictos]({{page.root}}/09-conflict/) +hubo un desafío que preguntó, +"¿Qué hace Git? +cuando hay un conflicto en una imagen o algún otro archivo no textual +que está almacenado en el control de la versión?" -We will now revisit this in more detail. +Ahora revisitaremos esto con más detalle. -Many people want to version control non-text files, such as images, PDFs and Microsoft Office or LibreOffice documents. -It is true that Git can handle these filetypes (which fall under the banner of "binary" file types). -However, just because it *can* be done doesn't mean it *should* be done. +Muchas personas desean controlar versiones que no sean archivos de texto, como imágenes, archivos PDF y documentos de Microsoft Office o LibreOffice. +Es cierto que Git puede manejar estos tipos de archivos (que caen bajo el título de tipos de archivos "binarios"). +Sin embargo, solo porque *se puede* hacer no significa que *se deba* hacer. -Much of Git's magic comes from being able to do line-by-line comparisons ("diffs") between files. -This is generally easy for programming source code and marked up text. -For non-text files, a diff can usually only detect that the files have changed -but can't say how or where. +Gran parte de la magia de Git proviene de poder hacer comparaciones línea por línea ("diffs") entre archivos. +Esto es generalmente fácil para programar el código fuente y el texto marcado. +Para archivos que no son de texto, un diff generalmente solo puede detectar que los archivos han cambiado +pero no puedo decir cómo o dónde. -This has various impacts on Git's performance and will make it difficult to -compare different versions of your project. +Esto tiene varios impactos en el rendimiento de Git y hará que sea difícil +compare diferentes versiones de su proyecto. -For a basic example to show the difference it makes, -we're going to go see what would have happened if Dracula had tried -using outputs from a word processor instead of plain text. +Para un ejemplo básico para mostrar la diferencia que hace, +vamos a ver qué hubiera pasado si Drácula hubiera intentado +utilizando salidas de un procesador de texto en lugar de texto sin formato. -Create a new directory and go into it: +Crea un nuevo directorio y entra en él: ~~~ $ mkdir planets-nontext @@ -148,16 +148,16 @@ $ cd planets-nontext ~~~ {: .bash} -Use a program such as Microsoft Word or LibreOffice Writer to create a new document. -Enter the same text that we began with before: +Use un programa como Microsoft Word o LibreOffice Writer para crear un documento nuevo. +Ingrese el mismo texto con el que comenzamos antes: ~~~ Cold and dry, but everything is my favorite color ~~~ {: .output} -Save the document into the `planets-nontext` directory with the name of `mars.doc`. -Back in the terminal, run the usual commands for setting up a new Git repository: +Guarde el documento en el directorio `planets-nontext` con el nombre de `mars.doc`. +De vuelta en la terminal, ejecute los comandos habituales para configurar un nuevo repositorio de Git: ~~~ $ git init @@ -166,7 +166,7 @@ $ git commit -m "Starting to think about Mars" ~~~ {: .bash} -Then make the same changes to `mars.doc` that we (or Vlad) previously made to `mars.txt`. +Luego haga los mismos cambios a `mars.doc` que nosotros (o Vlad) previamente hicimos a `mars.txt`. ~~~ Cold and dry, but everything is my favorite color @@ -174,8 +174,8 @@ The two moons may be a problem for Wolfman ~~~ {: .output} -Save and close the word processor. -Now see what Git thinks of your changes: +Guarde y cierre el procesador de texto. +Ahora mira lo que Git piensa de tus cambios: ~~~ $ git diff @@ -189,7 +189,7 @@ Binary files a/mars.doc and b/mars.doc differ ~~~ {: .output} -Compare this to the earlier `git diff` obtained when using text files: +Compare esto con el anterior `git diff` obtenido al usar archivos de texto: ~~~ diff --git a/mars.txt b/mars.txt @@ -202,37 +202,37 @@ index df0654a..315bf3a 100644 ~~~ {: .output} -Notice how plain text files give a much more informative diff. -You can see exactly which lines changed and what the changes were. +Observe cómo los archivos de texto plano dan una diferencia mucho más informativa. +Puede ver exactamente qué líneas cambiaron y cuáles fueron los cambios. -An uninformative `git diff` is not the only consequence of using Git on binary files. -However, most of the other problems boil down to whether or not a good diff is possible. +Un `git diff` no informativo no es la única consecuencia de usar Git en archivos binarios. +Sin embargo, la mayoría de los otros problemas se reducen a si es posible o no una buena diferencia. -This isn't to say you should *never* use Git on binary files. -A rule of thumb is that it's OK if the binary file won't change very often, -and if it does change, you don't care about merging in small differences between versions. +Esto no quiere decir que *nunca* debes usar Git en archivos binarios. +Una regla de oro es que está bien si el archivo binario no cambiará muy a menudo, +y si cambia, no te importa fusionarte en pequeñas diferencias entre versiones. -We've already seen how a word processed report will fail this test. -An example that passes the test is a logo for your organization or project. -Even though a logo will be stored in a binary format such as `jpg` or `png`, -you can expect it will remain fairly static through the lifetime of your repository. -On the rare occasion that branding does change, -you will probably just want to replace the logo completely rather than merge little differences in. +Ya hemos visto cómo un informe procesado por palabra no pasará esta prueba. +Un ejemplo que pasa la prueba es un logotipo para su organización o proyecto. +Aunque un logotipo se almacenará en un formato binario, como `jpg` o `png`, +puede esperar que permanezca bastante estático durante la vida útil de su repositorio. +En la rara ocasión en que la marca cambia, +probablemente solo quiera reemplazar el logotipo por completo en lugar de combinar pequeñas diferencias. -## Removing a File +## Eliminar un archivo -Adding and modifying files are not the only actions one might take -when working on a project. It might be required to remove a file -from the repository. +Agregar y modificar archivos no son las únicas acciones que uno podría tomar +cuando se trabaja en un proyecto. Puede ser necesario para eliminar un archivo +del repositorio. -Create a new file for the planet Nibiru: +Crea un nuevo archivo para el planeta Nibiru: ~~~ $ echo "This is another name for fake planet X" > nibiru.txt ~~~ {: .bash} -Now add to the repository like you have learned earlier: +Ahora agregue al repositorio como lo aprendió anteriormente: ~~~ $ git add nibiru.txt @@ -247,8 +247,8 @@ nothing to commit, working directory clean ~~~ {: .output} -Nibiru is not a real planet. That was a silly idea. Let us remove -it from the disk and let Git know about it: +Nibiru no es un planeta real. Esa fue una idea tonta. Vamos a eliminar +desde el disco y deja que Git lo sepa: ~~~ $ git rm nibiru.txt @@ -266,22 +266,22 @@ Changes to be committed: ~~~ {: .output} -The change has been staged. Now commit the removal, and remove the -file from the repository itself. Note that the file will be removed -in the new commit. The previous commit will still -have the file, if you were to retrieve that specific commit. +El cambio ha sido organizado. Ahora comprometa la eliminación y elimine +archivo del propio repositorio. Tenga en cuenta que el archivo se eliminará +en el nuevo compromiso La confirmación anterior seguirá +tener el archivo, si fueras a recuperar esa confirmación específica. ~~~ $ git commit -m 'Removing info on Nibiru. It is not a real planet!' ~~~ {: .bash} -## Removing a File with Unix +## Eliminar un archivo con Unix -Sometimes we might forget to remove the file through Git. If you removed the -file with Unix `rm` instead of using `git rm`, no worries, -Git is smart enough to notice the missing file. Let us recreate the file and -commit it again. +A veces podríamos olvidar eliminar el archivo a través de Git. Si eliminaste el +archivo con Unix `rm` en lugar de usar` git rm`, sin preocupaciones, +Git es lo suficientemente inteligente como para notar el archivo perdido. Vamos a recrear el archivo y +cometerlo de nuevo. ~~~ $ echo "This is another name for fake planet X" > nibiru.txt @@ -290,7 +290,7 @@ $ git commit -m 'adding nibiru again' ~~~ {: .bash} -Now we remove the file with Unix `rm`: +Ahora eliminamos el archivo con Unix `rm`: ~~~ $ rm nibiru.txt @@ -310,10 +310,10 @@ no changes added to commit (use "git add" and/or "git commit -a") ~~~ {: .output} -See how Git has noticed that the file `nibiru.txt` has been removed -from the disk. The next step is to "stage" the removal of the file -from the repository. This is done with the command `git rm` just as -before. +Vea cómo Git ha notado que el archivo `nibiru.txt` ha sido eliminado +del disco. El siguiente paso es "escenificar" la eliminación del archivo +del repositorio. Esto se hace con el comando `git rm` igual que +antes de. ~~~ $ git rm nibiru.txt @@ -331,26 +331,26 @@ Changes to be committed: ~~~ {: .output} -The change that was made in Unix has now been staged and needs to be -committed. +El cambio que se hizo en Unix ahora se ha organizado y debe ser +comprometido. ~~~ $ git commit -m 'Removing info on Nibiru, again!' ~~~ {: .bash} -## Renaming a File +## Renombrar un archivo -Another common change when working on a project is to rename a file. +Otro cambio común cuando se trabaja en un proyecto es cambiar el nombre de un archivo. -Create a file for the planet Krypton: +Crea un archivo para el planeta Krypton: ~~~ $ echo "Superman's home planet" > krypton.txt ~~~ {: .bash} -Add it to the repository: +Añádalo al repositorio: ~~~ $ git add krypton.txt @@ -358,10 +358,10 @@ $ git commit -m 'Adding planet Krypton' ~~~ {: .bash} -We all know that Superman moved to Earth. Not that he had much -choice. Now his home planet is Earth. +Todos sabemos que Superman se mudó a la Tierra. No es que tuviera mucho +elección. Ahora su planeta de origen es la Tierra. -Rename the file `krypton.txt` to `earth.txt` with Git: +Cambie el nombre del archivo `krypton.txt` a` earth.txt` con Git: ~~~ $ git mv krypton.txt earth.txt @@ -378,20 +378,21 @@ $ git status # ~~~ {: .output} -The final step is commit our change to the repository: + +El último paso es comprometer nuestro cambio al repositorio: ~~~ $ git commit -m 'Superman's home is now Earth' ~~~ {: .bash} -## Renaming a File with Unix +## Renombrar un archivo con Unix -If you forgot to use Git and you used Unix `mv` instead -of `git mv`, you will have a touch more work to do but Git will -be able to deal with it. Let's try again renaming the file, -this time with Unix `mv`. First, we need to recreate the -`krypton.txt` file: +Si olvidó usar Git y usó Unix `mv` en su lugar +de `git mv`, tendrás un poco más de trabajo que hacer, pero Git lo hará +ser capaz de lidiar con eso. Intentemos nuevamente cambiar el nombre del archivo, +esta vez con Unix `mv`. Primero, necesitamos recrear el +archivo `krypton.txt`: ~~~ $ echo "Superman's home planet" > krypton.txt @@ -400,8 +401,7 @@ $ git commit -m 'Adding planet Krypton again.' ~~~ {: .bash} -Let us rename the file and see what Git can figured out by itself: - +Vamos a renombrar el archivo y ver lo que Git puede descifrar por sí mismo: ~~~ $ mv krypton.txt earth.txt $ git status @@ -425,10 +425,10 @@ no changes added to commit (use "git add" and/or "git commit -a") ~~~ {: .output} -Git has noticed that the file `krypton.txt` has disappeared from the -file system and a new file `earth.txt` has showed up. +Git notó que el archivo `krypton.txt` ha desaparecido del +sistema de archivos y un nuevo archivo `earth.txt` ha aparecido. -Add those changes to the staging area: +Agregue esos cambios al área de ensayo: ~~~ $ git add krypton.txt earth.txt @@ -446,10 +446,10 @@ Changes to be committed: ~~~ {: .output} -Notice how Git has now figure out that the `krypton.txt` has not -disappeared it has simply been renamed. +Observe cómo Git ahora ha descubierto que el `krypton.txt` no tiene +desapareció simplemente ha sido renombrado. -The final step, as before, is to commit our change to the repository: +El último paso, como antes, es comprometer nuestro cambio al repositorio: ~~~ $ git commit -m 'Superman's home is Earth, told you before.' diff --git a/_extras/guide.md b/_extras/guide.md index 069c85de94..7e65a7e50e 100644 --- a/_extras/guide.md +++ b/_extras/guide.md @@ -3,293 +3,196 @@ layout: page title: "Instructor Notes" permalink: /guide/ --- -Using a software tool to handle the versions of your project files -lets you focus on the more interesting/innovative aspects of your project. - -* Version control's advantages - * It's easy to set up - * Every copy of a Git repository is a full backup of a project and its history - * A few easy-to-remember commands are all you need for most day-to-day version control tasks - * The [GitHub][github] hosting service provides a web-based collaboration service -* Two main concepts - * *commit*: a recorded set of changes in your project's files - * *repository*: the history of all your project's commits -* Why use GitHub? - * No need for a server: easy to set up - * GitHub's strong community: your colleagues are probably already there - -## Overall - -Version control might be the most important topic we teach, but Git is -definitely the most complicated tool. However, GitHub presently dominates the -open software repository landscape, so the time and effort required to teach -fundamental Git is justified and worthwhile. - -Because of this complexity, we don't teach novice learners about many -interesting topics, such as branching, hashes, and commit objects. - -Instead we try to convince them that version control is useful for researchers -working in teams or not, because it is - -* a better way to "undo" changes, -* a better way to collaborate than mailing files back and forth, and -* a better way to share your code and other scientific work with the world. - -## Teaching Notes - -* Resources for "splitting" your shell so that recent commands remain in view: https://github.com/rgaiacs/swc-shell-split-window. - -* Make sure the network is working *before* starting this lesson. - -* Drawings are particularly useful in this lesson: if you have a whiteboard, - [use it][drawings]! - -* Version control is usually not the first subject in a workshop, - so get learners to create a GitHub account after the session before. - Remind learners that the username and email they use for GitHub (and setup - during Git configuration) will be viewable to the public by default. - However, there are many reasons why a learner may not want their personal - information viewable, and GitHub has [resources for keeping an email address - private][github-privacy]. - -* If some learners are using Windows, there will inevitably be issues - merging files with different line endings. (Even if everyone's on - some flavor of Unix, different editors may or may not add a - newline to the last line of a file.) Take a moment to explain - these issues, since learners will almost certainly trip over them - again. If learners are running into line ending problems, GitHub - has a [page][github-line-endings] that helps with troubleshooting. -* We don't use a Git GUI in these notes because we haven't found one that - installs easily and runs reliably on the three major operating systems, and - because we want learners to understand what commands are being run. That - said, instructors should demo a GUI on their desktop at some point during - this lesson and point learners at [this page][github-gui]. +Usar una herramienta de software para manejar las versiones de tus archivos de proyecto +le permite enfocarse en los aspectos más interesantes / innovadores de su proyecto. -* Instructors should show learners graphical diff/merge tools like - [DiffMerge][diffmerge]. - -* When appropriate, explain that we teach Git rather than CVS, Subversion, or - Mercurial primarily because of GitHub's growing popularity: CVS and - Subversion are now seen as legacy systems, and Mercurial isn't nearly as - widely used in the sciences right now. +* Ventajas del control de versiones + * Es fácil de configurar + * Cada copia de un repositorio de Git es una copia de seguridad completa de un proyecto y su historial + * Unos pocos comandos fáciles de recordar son todo lo que necesita para la mayoría de las tareas cotidianas de control de versiones + * El servicio de alojamiento [GitHub][github] proporciona un servicio de colaboración basado en la web +* Dos conceptos principales + * *commit*: un conjunto de cambios registrados en los archivos de su proyecto + * *repositorio*: el historial de todas las confirmaciones de su proyecto +* ¿Por qué usar GitHub? + * No es necesario un servidor: fácil de configurar + * Comunidad fuerte de GitHub: tus colegas probablemente ya estén allí -* Further resources: - * [git-it][git-it] is a self-paced command-line Git demo, - with [git-it-electron][git-it-electron] its GitHub Desktop successor. - * [Code School][code-school] has a free interactive course, [Try Git][try-git]. - * for instructors, [the Git parable][git-parable] is useful background reading +## En general -## [Automated Version Control]({{ page.root }}/01-basics/) +El control de versiones podría ser el tema más importante que enseñamos, pero Git es +Definitivamente la herramienta más complicada. Sin embargo, GitHub actualmente domina el +abrir el panorama del repositorio de software, por lo que el tiempo y el esfuerzo necesarios para enseñar +Git fundamental está justificado y vale la pena. -* Ask, "Who uses 'undo' in their editor?" All say "Me". 'Undo' is the simplest - form of version control. - -* Give learners a five-minute overview of what version control does for them - before diving into the watch-and-do practicals. Most of them will have - tried to co-author papers by emailing files back and forth, or will have - biked into the office only to realize that the USB key with last night's - work is still on the kitchen table. Instructors can also make jokes about - directories with names like "final version", "final version revised", - "final version with reviewer three's corrections", "really final version", - and, "come on this really has to be the last version" to motivate version - control as a better way to collaborate and as a better way to back work up. - -## [Setting Up Git]({{ page.root }}/02-setup/) - -* We suggest instructors and students use `nano` as the text editor for this - lessons because - - * it runs in all three major operating systems, - * it runs inside the shell (switching windows can be confusing to students), and - * it has shortcut help at the bottom of the window. - - Please point out to students during setup that they can and should use - another text editor if they're already familiar with it. - -* When setting up Git, be very clear what learners have to enter: it is - common for them to edit the instructor's details (e.g. email). Check at - the end using `git config --list`. - -## [Creating a Repository]({{ page.root }}/03-create/) - -* When you do `git status`, Mac users may see a `.DS_Store` file showing as - untracked. This a file that Mac OS creates in each directory. - -* The challenge "Places to create repositories" tries to reinforce the idea - that the `.git` folder contains the whole Git repo and deleting this folder - undoes a `git init`. It also gives the learner the way to fix the common - mistake of putting unwanted folders (like `Desktop`) under version control. - - Instead of removing the `.git` folder directly, you can choose to move it - first to a safer directory and remove it from there: - - ~~~ - $ mv .git temp_git - $ rm -rf temp_git - ~~~ - {: .bash} - - The challenge suggests that it is a bad idea to create a Git repo inside another repo. - For more discussion on this topic, please see [this issue][repos-in-repos]. - -## [Tracking Changes]({{ page.root }}/04-changes/) - -* It's important that learners do a full commit cycle by themselves (make - changes, `git diff`, `git add`, and `git commit`). The "`bio` repository" - challenge does that. - -* This is a good moment to show a diff with a graphical diff tool. If you - skip it because you're short on time, show it once in GitHub. - -* One thing may cause confusion is recovering old versions. If, instead of - doing `$ git checkout f22b25e mars.txt`, someone does `$ git checkout - f22b25e`, they wind up in the "detached HEAD" state and confusion abounds. - It's then possible to keep on committing, but things like `git push origin - master` a bit later will not give easily comprehensible results. It also - makes it look like commits can be lost. To "fix" a "detached HEAD", simply - `git checkout master`. - -* This is a good moment to show a log within a Git GUI. If you skip it - because you're short on time, show it once in GitHub. - -## [Ignoring Things]({{ page.root }}/06-ignore/) - -Just remember that you can use wildcards and regular expressions to ignore a -particular set of files in `.gitignore`. - -## [Remotes in GitHub]({{ page.root }}/07-github/) +Debido a esta complejidad, no enseñamos a los principiantes acerca de muchos +temas interesantes, como ramificación, hash y commit de objetos. -* Make it clear that Git and GitHub are not the same thing: Git is an open - source version control tool, GitHub is a company that hosts Git - repositories in the web and provides a web interface to interact with repos - they host. +En cambio, tratamos de convencerlos de que el control de versiones es útil para los investigadores +trabajando en equipo o no, porque es -* If your learners are advanced enough to be comfortable with SSH, tell them - they can use keys to authenticate on GitHub instead of passwords, but don't - try to set this up during class: it takes too long, and is a distraction - from the core ideas of the lesson. +* una mejor forma de "deshacer" cambios, +* una mejor manera de colaborar que enviar y recibir archivos por correo, y +* una mejor manera de compartir tu código y otro trabajo científico con el mundo. -* It is very useful to draw a diagram showing the different repositories - involved. +## Notas de enseñanza -## [Collaborating]({{ page.root }}/08-collab/) +* Recursos para "dividir" su caparazón para que los comandos recientes permanezcan a la vista: https://github.com/rgaiacs/swc-shell-split-window. -* Decide in advance whether all the learners will work in one shared - repository, or whether they will work in pairs (or other small groups) in - separate repositories. The former is easier to set up; the latter runs - more smoothly. +* Asegúrese de que la red esté funcionando *antes* de comenzar esta lección. -* Role playing between two instructors can be effective when teaching the - collaboration and conflict sections of the lesson. One instructor can play - the role of the repository owner, while the second instructor can play the - role of the collaborator. If it is possible, try to use two projectors so - that the computer screens of both instructors can be seen. This makes for - a very clear illustration to the students as to who does what. +* Los dibujos son particularmente útiles en esta lección: si tiene una pizarra blanca, [usarlo][dibujos]! -* It is also effective to pair up students during this lesson and assign one - member of the pair to take the role of the owner and the other the role of - the collaborator. In this setup, challenges can include asking the - collaborator to make a change, commit it, and push the change to the remote - repository so that the owner can then retrieve it, and vice-versa. The - role playing between the instructors can get a bit "dramatic" in the - conflicts part of the lesson if the instructors want to inject some humor - into the room. +* El control de versiones generalmente no es el primer tema en un taller, así que haga que los alumnos creen una cuenta de GitHub después de la sesión anterior. Recuerde a los alumnos que el nombre de usuario y el correo electrónico que usan para GitHub (y configuración durante la configuración de Git) será visible para el público de manera predeterminada. Sin embargo, hay muchas razones por las cuales un alumno puede no querer su personal información visible, y GitHub tiene [recursos para mantener una dirección de correo electrónico privado][github-privacy]. -* If you don't have two projectors, have two instructors at the front of the - room. Each instructor does their piece of the collaboration demonstration - on their own computer and then passes the projector cord back and forth - with the other instructor when it's time for them to do the other part of - the collaborative workflow. It takes less than 10 seconds for each - switchover, so it doesn't interrupt the flow of the lesson. - And of course it helps to give each of the instructors a different-colored - hat, or put different-colored sticky notes on their foreheads. +* Si algunos estudiantes usan Windows, inevitablemente habrá problemas fusionando archivos con diferentes finales de línea. (Incluso si todos están encendidos un poco de sabor de Unix, diferentes editores pueden o no agregar una nueva línea a la última línea de un archivo.) Tómese un momento para explicar estos problemas, ya que los estudiantes seguramente tropezarán con ellos de nuevo. Si los estudiantes se están encontrando con problemas para terminar la línea, GitHub tiene una [página][github-line-endings] que ayuda a solucionar problemas. -* If you're the only instructor, the best way to create is clone the two - repos in your Desktop, but under different names, e.g., pretend one is your - computer at work: +* No usamos una GUI de Git en estas notas porque no hemos encontrado una que se instala fácilmente y funciona confiablemente en los tres principales sistemas operativos, y porque queremos que los alumnos entiendan qué comandos se están ejecutando. Ese dijo, los instructores deberían demo una GUI en su escritorio en algún momento durante esta lección y apunte a los alumnos en [esta página][github-gui]. - ~~~ - $ git clone https://github.com/vlad/planets.git planets-at-work - ~~~ - {: .bash} +* Los instructores deben mostrar a los alumnos herramientas gráficas de fusión / fusión como [DiffMerge][diffmerge]. -* It's very common that learners mistype the remote alias or the remote URL - when adding a remote, so they cannot `push`. You can diagnose this with - `git remote -v` and checking carefully for typos. - - To fix a wrong alias, you can do `git remote rename `. - - To fix a wrong URL, you can do `git remote set-url `. +* Cuando sea apropiado, explique que enseñamos a Git en lugar de CVS, Subversion, o Mercurial principalmente debido a la creciente popularidad de GitHub: CVS y Subversion ahora se ve como sistemas heredados, y Mercurial no es tan ampliamente utilizado en las ciencias en este momento. -* Before cloning the repo, be sure that nobody is inside another repo. The - best way to achieve this is moving to the `Desktop` before cloning: `cd && - cd Desktop`. +* Recursos adicionales: + * [git-it][git-it] es una demostración de Git de línea de comandos a tu propio ritmo, con [git-it-electron][git-it-electron] su sucesor de GitHub Desktop. + * [Code School][code-school] tiene un curso interactivo gratuito, [Try Git][try-git]. + * para instructores, [la parábola de Git][git-parábola] es una lectura de fondo útil -* If both repos are in the `Desktop`, have them to clone their collaborator - repo under a given directory using a second argument: +## [Control automatizado de versiones]({{page.root}}/01-basics/) - ~~~ - $ git clone https://github.com/vlad/planets.git vlad-planet - ~~~ - {: .bash} +* Pregunte, "¿Quién usa 'deshacer' en su editor?" Todos dicen "Yo". 'Deshacer' es el más simple forma de control de versiones. -* The most common mistake is that learners `push` before `pull`ing. If they - `pull` afterward, they may get a conflict. +* Ofrezca a los alumnos una visión general de cinco minutos de lo que el control de versión les hace antes de zambullirte en las prácticas de vigilancia. La mayoría de ellos tendrá intentó coautar documentos enviando archivos por correo electrónico, o tendrá en bicicleta en la oficina solo para darse cuenta de que la llave USB con la última noche el trabajo todavía está en la mesa de la cocina. Los instructores también pueden hacer bromas sobre directorios con nombres como "versión final", "versión final revisada", "versión final con las correcciones del revisor tres", "versión realmente final", y, "vamos, realmente tiene que ser la última versión" para motivar la versión control como una mejor manera de colaborar y como una mejor manera de respaldar el trabajo. -* Conflicts, sometimes weird, will start to arise. Stay tight: conflicts are - next. +## [Configuración de Git]({{page.root}}/02-setup/) -## [Conflicts]({{ page.root }}/09-conflict/) +* Sugerimos que los instructores y los estudiantes usen `nano` como editor de texto para este lecciones porque + * se ejecuta en los tres principales sistemas operativos, + * se ejecuta dentro del caparazón (las ventanas de conmutación pueden ser confusas para los estudiantes), y + * tiene ayuda contextual en la parte inferior de la ventana. -* Expect the learners to make mistakes. Expect *yourself* to make mistakes. This - happens because it is late in the lesson and everyone is tired. +    Señale a los alumnos durante la configuración que pueden y deben usar +    otro editor de texto si ya están familiarizados con él. -* If you're the only instructor, the best way to create a conflict is: +* Al configurar Git, tenga muy claro lo que los alumnos deben ingresar: es común que editen los detalles del instructor (por ejemplo, correo electrónico). Verifique en el final usando `git config --list`. - * Clone your repo in a different directory, pretending is your computer at - work: `git clone https://github.com/vlad/planets.git planets-at-work`. - * At the office, you make a change, commit and push. - * At your laptop repo, you (forget to pull and) make a change, commit and - try to push. - * `git pull` now and show the conflict. +## [Creación de un repositorio]({{page.root}}/03-create/) -* Learners usually forget to `git add` the file after fixing the conflict and - just (try to) commit. You can diagnose this with `git status`. +* Cuando haces `git status`, los usuarios de Mac pueden ver un archivo` .DS_Store` mostrando como sin seguimiento. Este es un archivo que Mac OS crea en cada directorio. -* Remember that you can discard one of the two parents of the merge: +* El desafío "Lugares para crear repositorios" intenta reforzar la idea que la carpeta `.git` contiene todo el repositorio de Git y eliminando esta carpeta deshace un `git init`. También le da al alumno la manera de solucionar el problema común error de poner carpetas no deseadas (como `Escritorio`) bajo control de versión. - * discard the remote file, `git checkout --ours conflicted_file.txt` - * discard the local file, `git checkout --theirs conflicted_file.txt` +    En lugar de eliminar la carpeta `.git` directamente, puede elegir moverla primero en un directorio más seguro y eliminarlo de allí: - You still have to `git add` and `git commit` after this. This is - particularly useful when working with binary files. +~~~ +$ mv .git temp_git +$ rm -rf temp_git +~~~ +{: .bash} -## [Open Science]({{ page.root }}/10-open/) +    El desafío sugiere que es una mala idea crear un repositorio de Git dentro de otro repositorio. +    Para obtener más información sobre este tema, consulte [este número][repos-in-repos]. -## [Licensing]({{ page.root }}/11-licensing/) +## [Cambios de seguimiento]({{page.root}}/04-changes/) -We teach about licensing because questions about who owns what, or can use -what, arise naturally once we start talking about using public services like -GitHub to store files. Also, the discussion gives learners a chance to catch -their breath after what is often a frustrating couple of hours. +* Es importante que los alumnos realicen un ciclo completo de compromiso por sí mismos (hacer cambios, `git diff`,` git add`, y `git commit`). El "repositorio de `bio`" desafío hace eso. -## [Citation]({{ page.root }}/12-citation/) +* Este es un buen momento para mostrar una diferencia con una herramienta gráfica de diferencia. Si tu omítalo porque tiene poco tiempo, muéstrelo una vez en GitHub. -## [Hosting]({{ page.root }}/13-hosting/) +* Una cosa puede causar confusión es la recuperación de versiones antiguas. Si, en lugar de haciendo `$ git checkout f22b25e mars.txt`, alguien hace `$ git checkout f22b25e`, terminan en el estado "HEAD separado" y la confusión abunda. Entonces es posible seguir cometiendo, pero cosas como `git push origen master` un poco más tarde no dará resultados fácilmente comprensibles. También hace que parezca que los commits se pueden perder. Para "arreglar" una "CABEZA separada", simplemente `git checkout master`. -A common concern for learners is having their work publicly available on -GitHub. While we encourage open science, sometimes private repos are the -only choice. It's always interesting to mention the options to have -web-hosted private repositories. +* Este es un buen momento para mostrar un registro dentro de una GUI de Git. Si te lo saltas porque tienes poco tiempo, muéstralo una vez en GitHub. -[code-school]: https://www.codeschool.com/ +## [Ignorando cosas]({{page.root}}/06-ignore/) + +Solo recuerda que puedes usar comodines y expresiones regulares para ignorar un un conjunto particular de archivos en `.gitignore`. + +## [Controles remotos en GitHub]({{page.root}}/07-github/) + +* Deje en claro que Git y GitHub no son lo mismo: Git es una persona abierta herramienta de control de versión fuente, GitHub es una compañía que aloja Git repositorios en la web y proporciona una interfaz web para interactuar con repositorios ellos hospedan + +* Si tus alumnos están lo suficientemente avanzados como para sentirse cómodos con SSH, cuéntales pueden usar claves para autenticarse en GitHub en lugar de contraseñas, pero no intente configurar esto durante la clase: lleva demasiado tiempo y es una distracción de las ideas centrales de la lección. + +* Es muy útil dibujar un diagrama que muestre los diferentes repositorios involucrado. + +## [Collaborating]({{page.root}}/08-collab/) + +* Decidir por adelantado si todos los alumnos trabajarán en una compartida repositorio, o si van a trabajar en parejas (u otros grupos pequeños) en repositorios separados. El primero es más fácil de configurar; el último corre más suave. + +* El juego de roles entre dos instructores puede ser efectivo cuando se enseña secciones de colaboración y conflicto de la lección. Un instructor puede jugar el papel del propietario del repositorio, mientras que el segundo instructor puede jugar el papel del colaborador. Si es posible, intente usar dos proyectores para que se pueden ver las pantallas de los dos instructores. Esto hace para una ilustración muy clara para los estudiantes sobre quién hace qué. + +* También es efectivo emparejar a los estudiantes durante esta lección y asignar uno miembro de la pareja para tomar el papel del propietario y el otro el papel de el colaborador En esta configuración, los desafíos pueden incluir preguntar al +    colaborador para hacer un cambio, comprometerlo y enviar el cambio al control remoto repositorio para que el propietario pueda recuperarlo y viceversa. los el juego de roles entre los instructores puede ser un poco "dramático" en el conflictos parte de la lección si los instructores quieren inyectar un poco de humor en la habitación. + +* Si no tiene dos proyectores, tenga dos instructores al frente del +    habitación. Cada instructor hace su parte de la demostración de colaboración en su propia computadora y luego pasa el cable del proyector de un lado a otro con el otro instructor cuando es hora de que hagan la otra parte de el flujo de trabajo colaborativo. Toma menos de 10 segundos para cada cambio, por lo que no interrumpe el flujo de la lección. Y, por supuesto, ayuda a dar a cada uno de los instructores un color diferente sombrero, o poner notas adhesivas de diferentes colores en sus frentes. + +* Si eres el único instructor, la mejor manera de crear es clonar los dos repositorios en su escritorio, pero con diferentes nombres, por ejemplo, pretender uno es su computadora en el trabajo: + +~~~ +$ git clone https://github.com/vlad/planets.git planets-at-work +~~~ +{: .bash} + +* Es muy común que los alumnos escriban mal el alias remoto o la URL remota cuando se agrega un control remoto, entonces no pueden 'presionar'. Puedes diagnosticar esto con `git remote -v` y comprobando cuidadosamente si hay errores tipográficos. + - Para arreglar un alias incorrecto, puedes hacer `git remote rename `. + - Para arreglar una URL incorrecta, puedes hacer `git remote set-url `. + +* Antes de clonar el repositorio, asegúrese de que nadie esté dentro de otro repositorio. los La mejor forma de lograr esto es pasar al `Escritorio` antes de la clonación: `cd && cd Desktop`. + +* Si ambos repos están en `Desktop`, pídales que clonen a su colaborador repo bajo un directorio dado usando un segundo argumento: + +~~~ +$ git clone https://github.com/vlad/planets.git vlad-planet +~~~ +{: .bash} + +* El error más común es que los estudiantes "empujan" antes de "tirar". Si ellos `pull` después, pueden tener un conflicto. + +* Conflictos, a veces extraños, comenzarán a surgir. Mantente apretado: los conflictos son siguiente. + +## [Conflicts]({{page.root}}/09-conflict/) + +* Espere que los alumnos cometan errores. Espere *usted mismo* para cometer errores. Esta sucede porque es tarde en la lección y todos están cansados. + +* Si eres el único instructor, la mejor forma de crear un conflicto es: + * Clona tu repositorio en un directorio diferente, pretendiendo que es tu computadora en +        trabajo: `git clone https://github.com/vlad/planets.git planets-at-work`. + * En la oficina, usted hace un cambio, se compromete y empuja. + * En su repositorio de la computadora portátil, usted (olvide tirar y) hacer un cambio, comprometerse y +        intenta empujar. + * `git pull` ahora y muestra el conflicto. + +* Los estudiantes generalmente se olvidan de 'agregar' el archivo después de arreglar el conflicto y solo (intenta) comprometer. Puedes diagnosticar esto con `git status`. + +* Recuerde que puede descartar uno de los dos padres de la combinación: + * descartar el archivo remoto, `git checkout --ours conflicted_file.txt` + * descartar el archivo local, `git checkout --the conflictigned_file.txt` + +Aún debe `git add` y` git commit` después de esto. Esto esparticularmente útil cuando se trabaja con archivos binarios. + +## [Ciencia abierta]({{page.root}}/10-open/) + +## [Licencias]({{page.root}}/11-licensing/) + +Enseñamos sobre licencias porque preguntas sobre quién posee qué o qué puede usar qué, surgen naturalmente una vez que comenzamos a hablar sobre el uso de servicios públicos como GitHub para almacenar archivos. Además, la discusión les da a los estudiantes la oportunidad de atrapar su aliento después de lo que a menudo es un par de horas frustrantes. + +## [Citation]({{page.root}}/12-citation/) + +## [Alojamiento]({{page.root}}/13-hosting/) + +Una preocupación común para los estudiantes es tener su trabajo a disposición del público en GitHub. Si bien fomentamos la ciencia abierta, a veces los repos privados son única opción. Siempre es interesante mencionar las opciones para tener repositorios privados alojados en la web. + +[escuela de código]: https://www.codeschool.com/ [diffmerge]: https://sourcegear.com/diffmerge/ -[drawings]: https://marklodato.github.io/visual-git-guide/index-en.html +[dibujos]: https://marklodato.github.io/visual-git-guide/index-en.html [git-it]: https://github.com/jlord/git-it [git-it-electron]: https://github.com/jlord/git-it-electron -[git-parable]: http://tom.preston-werner.com/2009/05/19/the-git-parable.html +[git-parábola]: http://tom.preston-werner.com/2009/05/19/the-git-parable.html [github]: https://github.com/ [github-gui]: http://git-scm.com/downloads/guis [github-line-endings]: https://help.github.com/articles/dealing-with-line-endings/#platform-all -[github-privacy]: https://help.github.com/articles/keeping-your-email-address-private/ +[github-privacy]: https://help.github.com/articles/ keeping-your-email-address-private/ [repos-in-repos]: https://github.com/swcarpentry/git-novice/issues/272 [try-git]: https://try.github.io diff --git a/_includes/all_keypoints.html b/_includes/all_keypoints.html index 8563df340a..44a7d9563b 100644 --- a/_includes/all_keypoints.html +++ b/_includes/all_keypoints.html @@ -1,7 +1,7 @@ {% comment %} - Display key points of all episodes for reference. + Muestra los puntos clave de todos los episodios para referencia. {% endcomment %} -

Key Points

+

Puntos Clave

{% for episode in site.episodes %} {% unless episode.break %} diff --git a/_includes/carpentries.html b/_includes/carpentries.html index a0e0181fc7..7b38087eda 100644 --- a/_includes/carpentries.html +++ b/_includes/carpentries.html @@ -1,17 +1,14 @@ {% comment %} - General description of Software and Data Carpentry. + Descripción general de Software y Data Carpentry. {% endcomment %}
Software Carpentry logo
- Since 1998, + Desde 1998, Software Carpentry - has been teaching researchers in science, engineering, medicine, and related disciplines - the computing skills they need to get more done in less time and with less pain. - Its volunteer instructors have run hundreds of events - for thousands of learners in the past two and a half years. + ha estado enseñando investigadores en ciencia, ingeniería, medicina y disciplinas relacionadas las habilidades informáticas que necesitan para hacer más en menos tiempo y con menos dolor. Sus instructores voluntarios han ejecutado cientos de eventos para miles de estudiantes en los últimos dos años y medio.

@@ -20,25 +17,17 @@ Data Carpentry logo
- Data Carpentry develops and teaches workshops on the fundamental data skills needed to conduct research. - Its target audience is researchers who have little to no prior computational experience, - and its lessons are domain specific, - building on learners' existing knowledge to enable them to quickly apply skills learned to their own research. + Data Carpentry desarrolla y enseña talleres sobre las habilidades de datos fundamentales necesarias para realizar investigaciones. Su público objetivo son los investigadores que tienen poca o ninguna experiencia computacional previa, y sus lecciones son específicas del dominio, aprovechando el conocimiento existente de los alumnos para permitirles aplicar rápidamente las habilidades aprendidas a su propia investigación.

- Library Carpentry logo + Library Carpentry logo
- Library Carpentry is made by librarians to help librarians - automate repetitive, boring, error-prone tasks; - create, maintain and analyse sustainable and reusable data; - work effectively with IT and systems colleagues; - better understand the use of software in research; - and much more. - Library Carpentry was the winner of the 2016 - British Library Labs Teaching and Learning Award. + Library Carpentry es hecho por bibliotecarios para ayudar a los bibliotecarios automatizar tareas repetitivas, aburridas y propensas a errores; crear, mantener y analizar datos sostenibles y reutilizables; trabaje eficazmente con los colegas de TI y sistemas; comprender mejor el uso del software en la investigación; y mucho más. + Library Carpentry fue el ganador del 2016 + Premio de enseñanza y aprendizaje de British Library Labs.
diff --git a/_includes/dc/intro.html b/_includes/dc/intro.html index 741aeebb52..c9d1aaec9f 100644 --- a/_includes/dc/intro.html +++ b/_includes/dc/intro.html @@ -1,18 +1,11 @@

Data Carpentry - aims to help researchers get their work done - in less time and with less pain - by teaching them basic research computing skills. - This hands-on workshop will cover basic concepts and tools, - including program design, version control, data management, - and task automation. - Participants will be encouraged to help one another - and to apply what they have learned to their own research problems. -

+tiene como objetivo ayudar a los investigadores a hacer su trabajo en menos tiempo y con menos dolor +   enseñándoles habilidades básicas de informática de investigación. Este taller práctico cubrirá conceptos básicos y herramientas, incluyendo el diseño del programa, control de versiones, administración de datos, +   y automatización de tareas. Se animará a los participantes a ayudarse mutuamente y aplicar lo que han aprendido a sus propios problemas de investigación.

- For more information on what we teach and why, - please see our paper + Para más información sobre lo que enseñamos y por qué, por favor mira nuestro papel "Best Practices for Scientific Computing".

diff --git a/_includes/dc/schedule.html b/_includes/dc/schedule.html index 6894a19e3b..9cde9f18ea 100644 --- a/_includes/dc/schedule.html +++ b/_includes/dc/schedule.html @@ -2,23 +2,23 @@

Day 1

- - - - - - + + + + + +
09:00 Automating tasks with the Unix shell
10:30 Coffee
12:00 Lunch break
13:00 Building programs with Python
14:30 Coffee
16:00 Wrap-up
09:00 Automatizar tareas con el terminal Unix
10:30 Café
12:00 Pausa para almorzar
13:00 Construyendo programas con Python
14:30 Café
16:00 Finalización

Day 2

- - - - - - + + + + + +
09:00 Version control with Git
10:30 Coffee
12:00 Lunch break
13:00 Managing data with SQL
14:30 Coffee
16:00 Wrap-up
09:00 Control de versiones con Git
10:30 Café
12:00 Pausa para almorzar
13:00 Administrar datos con SQL
14:30 Café
16:00 Finalización
diff --git a/_includes/dc/syllabus.html b/_includes/dc/syllabus.html index a325ceec22..602cf77a56 100644 --- a/_includes/dc/syllabus.html +++ b/_includes/dc/syllabus.html @@ -1,52 +1,52 @@
-

The Unix Shell

+

El Terminal de Unix

    -
  • Files and directories
    • +
  • Archivos y directorios
  • History and tab completion
    • -
  • Pipes and redirection
    • -
  • Looping over files
    • -
  • Creating and running shell scripts
    • -
  • Finding things
    • -
  • Reference...
    • +
  • Tuberías y redirección
    • +
  • Looping sobre archivos
    • +
  • Crear y ejecutar scripts de terminal
    • +
  • Encontrar cosas
    • +
  • Referencia...
-

Programming in Python

+

Programación en Python

    -
  • Using libraries
    • -
  • Working with arrays
    • -
  • Reading and plotting data
    • -
  • Creating and using functions
    • -
  • Loops and conditionals
    • -
  • Defensive programming
    • -
  • Using Python from the command line
    • -
  • Reference...
    • +
  • Uso de bibliotecas
    • +
  • Trabajando con matrices
    • +
  • Lectura y trazado de datos
    • +
  • Creación y uso de funciones
    • +
  • Bucles y condicionales
    • +
  • Programación defensiva
    • +
  • Usando Python desde la línea de comando
    • +
  • Referencia...
@@ -54,43 +54,43 @@

Programming in MATLAB

-

Version Control with Git

+

Control de versiones con Git

    -
  • Creating a repository
    • -
  • Recording changes to files: add, commit, ...
    • -
  • Viewing changes: status, diff, ...
    • -
  • Ignoring files
    • -
  • Working on the web: clone, pull, push, ...
    • -
  • Resolving conflicts
    • -
  • Open licenses
    • -
  • Where to host work, and why
    • -
  • Reference...
    • +
  • Creando un repositorio
    • +
  • Grabación de cambios en los archivos: add, commit, ...
    • +
  • Ver cambios: status, diff, ...
    • +
  • Ignorando archivos
    • +
  • Trabajando en la web: clone, pull, push, ...
    • +
  • Resolviendo conflictos
    • +
  • Licencias abiertas
    • +
  • Dónde alojar el trabajo y por qué
    • +
  • Referencia...

Open Refine

    -
  • Introduction to OpenRefine
    • -
  • Importing data
    • -
  • Basic functions
    • -
  • Advanced Functions
    • -
  • Reference...
    • +
  • Introducción a OpenRefine
    • +
  • Importar datos
    • +
  • Funciones básicas
    • +
  • Funciones avanzadas
    • +
  • Referencia...
diff --git a/_includes/dc/who.html b/_includes/dc/who.html index 2d8e94ae37..491bf712cf 100644 --- a/_includes/dc/who.html +++ b/_includes/dc/who.html @@ -1,8 +1,5 @@

- Who: - The course is aimed at graduate students and other researchers. - - You don't need to have any previous knowledge of the tools - that will be presented at the workshop. - +Quién: +   El curso está dirigido a estudiantes de posgrado y otros investigadores. +   No es necesario que tenga ningún conocimiento previo de las herramientasque será presentado en el taller.

diff --git a/_includes/episode_break.html b/_includes/episode_break.html index 36d2d2fad9..ae91a26fdf 100644 --- a/_includes/episode_break.html +++ b/_includes/episode_break.html @@ -1,5 +1,5 @@ {% comment %} - Display a break's timings in a box similar to a learning episode's. +Muestra los tiempos de un descanso en una caja similar a la de un episodio de aprendizaje. {% endcomment %}

Overview

diff --git a/_includes/episode_keypoints.html b/_includes/episode_keypoints.html index 2baa53ef0c..02c212e8ee 100644 --- a/_includes/episode_keypoints.html +++ b/_includes/episode_keypoints.html @@ -1,8 +1,8 @@ {% comment %} - Display key points for an episode. +Muestra los puntos clave de un episodio. {% endcomment %}
-

Key Points

+

Puntos Clave

    {% for keypoint in page.keypoints %}
  • {{ keypoint|markdownify }}
    • diff --git a/_includes/episode_navbar.html b/_includes/episode_navbar.html index b9f85f6bda..130a4f9dbe 100644 --- a/_includes/episode_navbar.html +++ b/_includes/episode_navbar.html @@ -1,27 +1,27 @@ {% comment %} - Navigation bar for an episode. +Barra de navegación para un episodio. {% endcomment %}
    -
    -

    +
    +

    {% if page.previous.url %} - previous episode + episodio anterior {% else %} - lesson home + casa de lección {% endif %}

    -
    +
    {% if include.episode_navbar_title %}

    {{ site.title }}

    {% endif %}
    -
    -

    +
    +

    {% if page.next.url %} - next episode + siguiente episodio {% else %} - lesson home + casa de lección {% endif %}

    diff --git a/_includes/episode_overview.html b/_includes/episode_overview.html index cb87e0f66b..5b6c49683d 100644 --- a/_includes/episode_overview.html +++ b/_includes/episode_overview.html @@ -1,17 +1,17 @@ {% comment %} - Display an episode's timings and learning objectives. +Muestre los tiempos y los objetivos de aprendizaje de un episodio. {% endcomment %}

    Overview

    - Teaching: {{ page.teaching }} min + Enseñando: {{ page.teaching }} min
    - Exercises: {{ page.exercises }} min + Prácticas: {{ page.exercises }} min
    - Questions + Preguntas
      {% for question in page.questions %}
    • {{ question|markdownify }}
      • @@ -24,7 +24,7 @@

      Overview

      - Objectives + Objetivos
        {% for objective in page.objectives %}
      • {{ objective|markdownify }}
        • diff --git a/_includes/javascript.html b/_includes/javascript.html index a2066c2028..35e6f2a668 100644 --- a/_includes/javascript.html +++ b/_includes/javascript.html @@ -1,5 +1,5 @@ {% comment %} - Javascript used in lesson and workshop pages. +Javascript utilizado en las páginas de lecciones y talleres. {% endcomment %} diff --git a/_includes/lc/intro.html b/_includes/lc/intro.html index 6794b542c3..56aae5a1dc 100644 --- a/_includes/lc/intro.html +++ b/_includes/lc/intro.html @@ -1,19 +1,16 @@

        - Library Carpentry - is made by librarians, for librarians to help you: -

        -
          -
        • automate repetitive, boring, error-prone tasks
          • -
        • create, maintain and analyse sustainable and reusable data
          • -
        • work effectively with IT and systems colleagues
          • -
        • better understand the use of software in research
          • -
        • and much more...
          • -
        -

        - - Library Carpentry introduces you to the fundamentals of computing - and provides you with a platform for further self-directed learning. - For more information on what we teach and why, please see our paper - "Library Carpentry: software skills training for library professionals". - + Library Carpentry está hecho por bibliotecarios, para que los bibliotecarios lo ayuden:

        +
          +
        • automatizar tareas repetitivas, aburridas y propensas a errores
          • +
        • crear, mantener y analizar datos sostenibles y reutilizables
          • +
        • trabaja eficazmente con los colegas de TI y sistemas
          • +
        • comprender mejor el uso del software en la investigación
          • +
        • y mucho más ...
          • +
        +

        + +     Library Carpentry te presenta los fundamentos de la informática y le proporciona una plataforma para un mayor aprendizaje autodirigido. Para obtener más información sobre lo que enseñamos y por qué consulte nuestro documento +      " Library Carpentry: software skills training for library professionals". + +

        \ No newline at end of file diff --git a/_includes/lc/schedule.html b/_includes/lc/schedule.html index cc2b592024..df6af32cce 100644 --- a/_includes/lc/schedule.html +++ b/_includes/lc/schedule.html @@ -1,24 +1,24 @@
        -
        -

        Day 1

        - - - - - - - +
        +

        Día 1

        +
        09:00 Data Intro for Librarians
        10:30 Coffee
        12:00 Lunch break
        13:00 Shell Lessons for Libraries
        14:30 Coffee
        16:00 Wrap-up
        + + + + + +
        09:00Introducción de datos para bibliotecarios
        10:30Café
        12:00Almuerzo
        13:00Lecciones de termina de Unix para bibliotecas
        14:30Café
        16:00Cierre
        -
        -
        -

        Day 2

        - - - - - - - -
        09:00 Git Intro for Librarians
        10:30 Coffee
        12:00 Lunch break
        13:00 OpenRefine for Librarians
        14:30 Coffee
        16:00 Wrap-up
        -
        +
        +
        +

        Día 2

        + + + + + + + +
        09:00Introducción de Git para bibliotecarios
        10:30Café
        12:00Almuerzo
        13:00OpenRefine para bibliotecarios
        14:30Café
        16:00Cierre
        +
      diff --git a/_includes/lc/syllabus.html b/_includes/lc/syllabus.html new file mode 100644 index 0000000000..302d33ee1b --- /dev/null +++ b/_includes/lc/syllabus.html @@ -0,0 +1,69 @@ +
      +
      +

      Introducción de datos

      +
        +
      • Introducción a los datos
        • +
      • Jargon revienta
        • +
      • Atajos de teclado
        • +
      • Formatos de texto sin formato
        • +
      • Nombrar archivos
        • +
      • Expresiones regulares
        • +
      • Referencia...
        • +
      +
      +
      +

      La Termina de Unix

      +
        +
      • Archivos y directorios
        • +
      • History and tab completion
        • +
      • Contando y clasificando contenidos en archivos
        • +
      • Tuberías y redirección
        • +
      • Minería o búsqueda en archivos
        • +
      • Referencia...
        • +
      +
      + +
      + +
      +
      +

      Control de versiones con Git

      +
        +
      • Creando un repositoria
        • +
      • Configurando Git
        • +
      • Grabación de cambios en los archivos: add, commit, ...
        • +
      • Viendo los cambios de estado con status
        • +
      • Trabajando en la web: clone, pull, push, ...
        • +
      • Dónde alojar el trabajo y por qué
        • +
      • Referencia...
        • +
      +
      +
      +
      +

      OpenRefine

      +
        +
      • Introducción a OpenRefine
        • +
      • Importar datos
        • +
      • Funciones básicas
        • +
      • Funciones avanzadas
        • +
      • Referencia...
        • +
      +
      +
      +
      + diff --git a/_includes/lc/syllabys.html b/_includes/lc/syllabys.html deleted file mode 100644 index 4dc20776d4..0000000000 --- a/_includes/lc/syllabys.html +++ /dev/null @@ -1,69 +0,0 @@ -
      -
      -

      Data Intro

      -
        -
      • Intro to data
        • -
      • Jargon busting
        • -
      • Keyboard shortcuts
        • -
      • Plain text formats
        • -
      • Naming files
        • -
      • Regular expressions
        • -
      • Reference...
        • -
      -
      -
      -

      The Unix Shell

      -
        -
      • Files and directories
        • -
      • History and tab completion
        • -
      • Counting and sorting contents in files
        • -
      • Pipes and redirection
        • -
      • Mining or searching in files
        • -
      • Reference...
        • -
      -
      - -
      - -
      -
      -

      Version Control with Git

      -
        -
      • Creating a repository
        • -
      • Configuring git
        • -
      • Recording changes to files: add, commit, ...
        • -
      • Viewing state changes with status
        • -
      • Working on the web: clone, pull, push, ...
        • -
      • Where to host work, and why
        • -
      • Reference...
        • -
      -
      -
      -
      -

      Open Refine

      -
        -
      • Introduction to OpenRefine
        • -
      • Importing data
        • -
      • Basic functions
        • -
      • Advanced Functions
        • -
      • Reference...
        • -
      -
      -
      -
      - diff --git a/_includes/lc/who.html b/_includes/lc/who.html index fd9b38c47c..1827cc25b8 100644 --- a/_includes/lc/who.html +++ b/_includes/lc/who.html @@ -1,8 +1,7 @@

      - Who: - The course is for librarians, archivists, and other information workers. - - You don't need to have any previous knowledge of the tools that - will be presented at the workshop. - +   Quién: + El curso es para bibliotecarios, archivistas y otros trabajadores de la información. + + No es necesario que tenga ningún conocimiento previo de las herramientas que será presentado en el taller. +

      diff --git a/_includes/lesson_footer.html b/_includes/lesson_footer.html index fa5d888701..c781a021c1 100644 --- a/_includes/lesson_footer.html +++ b/_includes/lesson_footer.html @@ -1,5 +1,5 @@ {% comment %} - Footer for lesson pages. +  Pie de página para las páginas de lecciones. {% endcomment %}
    diff --git a/_includes/links.md b/_includes/links.md index a163786df7..2dfecd6d64 100644 --- a/_includes/links.md +++ b/_includes/links.md @@ -1,23 +1,23 @@ [cc-by-human]: https://creativecommons.org/licenses/by/4.0/ [cc-by-legal]: https://creativecommons.org/licenses/by/4.0/legalcode -[concept-maps]: http://swcarpentry.github.io/instructor-training/08-memory/ -[contact]: mailto:lessons@software-carpentry.org -[contrib-covenant]: http://contributor-covenant.org/ +[concept-maps]: https://carpentries.github.io/instructor-training/05-memory/ +[email]: mailto:lessons@software-carpentry.org +[contrib-covenant]: https://contributor-covenant.org/ [contributing]: {{ site.github.repository_url }}/blob/gh-pages/CONTRIBUTING.md [cran-checkpoint]: https://cran.r-project.org/web/packages/checkpoint/index.html [cran-knitr]: https://cran.r-project.org/web/packages/knitr/index.html [cran-stringr]: https://cran.r-project.org/web/packages/stringr/index.html [github-importer]: https://import.github.com/ -[importer]: http://import.github.com/new +[importer]: https://github.com/new/import [jekyll-collection]: https://jekyllrb.com/docs/collections/ [jekyll-install]: https://jekyllrb.com/docs/installation/ [jekyll-windows]: http://jekyll-windows.juthilo.com/ [jekyll]: https://jekyllrb.com/ [jupyter]: https://jupyter.org/ -[mit-license]: http://opensource.org/licenses/mit-license.html +[mit-license]: https://opensource.org/licenses/mit-license.html [morea]: https://morea-framework.github.io/ -[numfocus]: http://numfocus.org/ -[osi]: http://opensource.org +[numfocus]: https://numfocus.org/ +[osi]: https://opensource.org [pandoc]: https://pandoc.org/ [paper-now]: https://github.com/PeerJ/paper-now [python-gapminder]: https://swcarpentry.github.io/python-novice-gapminder/ @@ -25,11 +25,11 @@ [r-markdown]: http://rmarkdown.rstudio.com/ [rstudio]: https://www.rstudio.com/ [ruby-install-guide]: https://www.ruby-lang.org/en/downloads/ -[ruby-installer]: http://rubyinstaller.org/ +[ruby-installer]: https://rubyinstaller.org/ [rubygems]: https://rubygems.org/pages/download/ [styles]: https://github.com/swcarpentry/styles/ -[training]: http://swcarpentry.github.io/instructor-training/ +[training]: https://swcarpentry.github.io/instructor-training/ [workshop-repo]: {{ site.workshop_repo }} [yaml]: http://yaml.org/ [coc]: https://software-carpentry.org/conduct/ -[coc-reporting]: https://software-carpentry.org/CoC-reporting/ \ No newline at end of file +[coc-reporting]: https://software-carpentry.org/CoC-reporting/ diff --git a/_includes/main_title.html b/_includes/main_title.html index 8e22ced110..283a2f7796 100644 --- a/_includes/main_title.html +++ b/_includes/main_title.html @@ -1,4 +1,4 @@ {% comment %} - Main title for lesson pages. +Título principal para las páginas de la lección. {% endcomment %} -

    {{ site.title }}{% if page.title %}: {{ page.title }}{% endif %}

    +

    {{ site.title }}{% if page.title %}: {{ page.title }}{% endif %}

    diff --git a/_includes/navbar.html b/_includes/navbar.html index 7782c9dd5b..e1f8acfb62 100644 --- a/_includes/navbar.html +++ b/_includes/navbar.html @@ -1,17 +1,17 @@ {% comment %} - Lesson navigation bar. + Barra de navegación de la lección. {% endcomment %}