29 Notas

Notas para el futuro

29.1 Preguntas comunes sobre el flujo de trabajo

29.1.1 Problemas comunes y cómo recuperarse / evitarlas

https://twitter.com/JennyBryan/status/743457387730735104

29.1.2 Mantener algo fuera de Git

Enumérelo en .gitignore.

29.1.3 No quería hacerle commit a eso

Hacer commit a cosas que no quería (demasiado grandes, secretas, etc.). Cómo deshacer.

29.2 git stuff

Explicadores de Git, diagramas abundantes

https://twitter.com/JennyBryan/status/743548245645791232

Una referencia visual de Git
http://marklodato.github.io/visual-git-guide/index-en.html

Un modelo de branch en Git exitoso
http://nvie.com/posts/a-successful-git-branching-model/

Un modelo de branch en Git exitoso pero considerado nocivo https://barro.github.io/2016/02/a-succesful-git-branching-model-considered-harmful/

Tutoriales de Git en Atlassian https://www.atlassian.com/git/tutorials/

Lecciones para novatos de Git por Software Carpentry
http://swcarpentry.github.io/git-novice/

Slides de Michael Freeman sobre colaboración en Git
http://slides.com/michaelfreeman/git-collaboration#/

Materiales de formación GitHub
https://services.github.com/kit/

Git para mayores de 4 años https://www.youtube.com/watch?v=3m7BgIvC-uQ

Aprender branch en Git http://learngitbranching.js.org

Una serie de pasos del flujo de trabajo en Git http://vallandingham.me/git-workflow.html

  • Parte 1: Presentación de branches
  • Parte 2: Revisión de pull requests
  • Parte 3: Revisión de pull requests localmente
  • Parte 4: Fusión de pull requests

Git desde adentro hacia afuera https://codewords.recurse.com/issues/two/git-from-the-inside-out

29.3 La repetida enmienda

Una forma de hacer commit a menudo, sin exponer su trabajo en progreso en GitHub o sin crear un historial muy desordenado.

Haga cambios. Llegue a un punto de parada decente. Pruebe, compruebe, si un paquete … compile un análisis …. ¿Nada se dañó?

Haga commit. No haga push

Haga más cambios. Continúe probando, comprobando o verificando. Inspeccione los diffs para ver lo que está cambiando.

¿Hay algo dañado? Utilice un restablecimiento adecuado para retroceder.

¿Están mejorando las cosas? Haga commit pero arregle el commit anterior.

Siga así hasta que haya construido un commit del que pueda estar orgulloso.

Ahora haga push.

Es importante no subir los commits enmendados a menos que usted realmente sepa lo que está haciendo y puede estar absolutamente seguro que nadie más haya descargado su trabajo.

29.4 Recuperación de desastres

http://stackoverflow.com/questions?sort=votes

Descompóngalo:

  • ¿Hay algún problema con el sistema de archivos/archivos?
  • ¿Está el repositorio de git desordenado?
  • ¿Cómo puede evitarse que esto vuelva a suceder?

Técnicas de evitación de rebase.

Estado sin cabeza. Rebase el infierno.

Qué hacer cuando no se puede, por ejemplo, cambiar los branches. Hacer commits al trabajo en progreso.

29.5 Emplear código en R en GitHub

Inspeccionar

Buscar

Cómo ser un usuario útil de R:

  • estando informado: desarrollo
  • usando issues para reportar errores, solicitudes de características
  • haciendo pull requests

29.6 Flujo de trabajo y psicología

Estrés de trabajar de forma abierta

Flujos de trabajo para grupos de 1, 2, 5, 10

29.7 Cómo funcionan los enlaces de corchetes

Contexto: prefiere vincularse con texto, no con un capítulo o número de sección.

  • ¡BUENO! Aquí hay un enlace a [Colaboradores].
  • MALO. Puede ver colaboradores en 2.

Hechos y vocabulario

  • Cada capítulo es un archivo. Estos archivos deben comenzar con el título del capítulo utilizando un encabezado de nivel uno, por ejemplo, # Título del capítulo.
  • Un capítulo puede estar formado por secciones, indicadas por encabezados de nivel inferior, por ejemplo, ## Una sección dentro del capítulo.
  • Hay tres maneras de abordar una sección al crear enlaces dentro de su libro:
    • Identificador explícito: En # My header {#foo} el identificador explícito es foo.
    • Identificador generado automáticamente: my-header es el auto identificador para # My header. Pandoc crea auto-identificadores de acuerdo con las reglas establecidas en Extensión: auto-identificadores.
    • El texto de encabezado, e.g., My header se usará igual que en Referencia de encabezado implícita. Vea Extension: implicit_header_references para saber más.
  • Las 3 formas se pueden utilizar para crear referencias cruzadas, pero se construyen los vínculos de manera diferente.
  • Ventaja de la identificación explícita: Es menos probable que actualice el encabezado de la sección y luego olvide hacer ediciones coincidentes con las referencias en otras partes del libro.

Cómo crear vínculos basados en texto mediante identificadores explícitos, identificadores automáticos y referencias implícitas:

  • Utilice la referencia implícita solo para obtener un enlace donde el texto es exactamente el encabezado de la sección:
    • [Preséntesele a Git] Preséntesele a Git
    • [Éxito y sistemas operativos] [Éxito y sistemas operativos]
  • Puede proporcionar texto personalizado para el vínculo con los 3 métodos de direccionar una sección:
    • Referencia implícita del encabezado: [link text][Clientes recomendados de Git] link text
    • Identificador explícito: [hola git! Soy Jenny](#hello-git) hola git Soy Jenny
    • Identificador automático: [el texto que quiera](#recommended-git-clients) el texto que quiera