12 cosas geniales que puedes hacer con GitHub

No puedo por mi vida pensar en una introducción, entonces …

# 1 Editar código en GitHub.com

Comenzaré con uno que creo que la mayoría de la gente conoce (aunque no lo sabía hasta hace una semana).

Cuando estás en GitHub, mirando un archivo (cualquier archivo de texto, cualquier repositorio), hay un pequeño lápiz en la parte superior derecha. Si hace clic en él, puede editar el archivo. Cuando hayas terminado, haz clic en Proponer cambio de archivo y GitHub te buscará el repositorio y creará una solicitud de extracción.

¿No es tan salvaje? ¡Crea la horquilla para ti!

No es necesario bifurcar, tirar y cambiar localmente, presionar y crear un PR.

No es un RP real

Esto es ideal para corregir errores tipográficos y una idea algo terrible para editar el código.

# 2 Pegando imágenes

No solo está limitado al texto en comentarios y descripciones de temas. ¿Sabía que puede pegar una imagen directamente desde el portapapeles? Cuando pegues, verás que se sube (a la "nube", sin duda) y se convierte en el descuento para mostrar una imagen.

Ordenado.

# 3 Código de formateo

Si desea escribir un bloque de código, puede comenzar con tres retrocesos, tal como aprendió al leer la página de Mastering Markdown , y GitHub intentará adivinar qué idioma está escribiendo.

Pero si publica un fragmento de algo como Vue, Typescript o JSX, puede especificarlo explícitamente para obtener el resaltado correcto.

Tenga en cuenta el ```jsx en la primera línea aquí:

… lo que significa que el fragmento se procesa correctamente:

(Por cierto, esto se extiende a la esencia. Si le das a un .jsx la extensión de .jsx obtendrás resaltado de sintaxis JSX.)

Aquí hay una lista de todas las sintaxis compatibles .

# 4 Cuestiones de cierre con palabras mágicas en RP

Supongamos que está creando una solicitud de extracción que soluciona el problema # 234. Puede poner el texto "arreglos # 234" en la descripción de su PR (o de hecho en cualquier lugar en cualquier comentario sobre el PR).

Entonces, fusionar el PR automáticamente cierra ese problema. ¿No es genial?

Hay más para aprender en la ayuda .

# 5 Vinculación a los comentarios

¿Alguna vez quisiste vincular a un comentario en particular pero no pudiste averiguar cómo? Eso es porque no sabes cómo hacerlo. Pero esos días están detrás de ti, amigo mío, porque estoy aquí para decirte que al hacer clic en la fecha / hora al lado del nombre, aparece cómo vinculas un comentario.

¡Oye, Gaearon consiguió una foto!

# 6 Vinculación al código

Entonces quiere vincular a una línea específica de código. Lo entiendo.

Intente esto: mientras mira el archivo, haga clic en el número de línea al lado de dicho código.

Whoa, ¿viste eso? ¡La URL se actualizó con el número de línea! Si mantiene presionada la tecla Mayús y hace clic en otro número de línea, SHAZAAM, la URL se actualiza nuevamente y ahora ha resaltado un rango de líneas.

Compartir esa URL se vinculará a este archivo y esas líneas. Pero espera, eso apunta a la rama actual. ¿Qué pasa si el archivo cambia? Tal vez un enlace permanente al archivo en su estado actual es lo que buscas.

Soy flojo, así que hice todo lo anterior en una captura de pantalla:

Hablando de URL …

# 7 Usando la URL de GitHub como la línea de comando

Navegar alrededor de GitHub usando la interfaz de usuario está todo bien. Pero a veces la forma más rápida de llegar a donde quieres llegar es simplemente escribirla en la URL. Por ejemplo, si quiero saltar a una rama en la que estoy trabajando y ver el diff con el maestro, puedo escribir /compare/branch-name después de mi nombre de repositorio.

Eso me llevará a la página de diferencias para esa rama:

Sin embargo, eso es un problema con el maestro, si estuviera trabajando fuera de una rama de integración, escribiría /compare/ integration-branch... my-branch

Para ti los atajos de teclado, ctrl + L o cmd + L saltarán el cursor hacia arriba en la URL (al menos en Chrome). Esto, junto con el hecho de que su navegador se completará automáticamente, puede hacer que sea una forma práctica de saltar entre sucursales.

Pro-tip: use las teclas de flecha para desplazarse por las sugerencias de autocompletado de Chrome y pulse shift + delete para eliminar un elemento del historial (por ejemplo, una vez que se fusiona una rama).

(Realmente me pregunto si esos atajos serían más fáciles de leer si los hiciera como shift + delete . Pero técnicamente el '+' no es parte de eso, así que no me siento cómodo con eso. Esto es lo que me mantiene despierto. por la noche, Rhonda.)

# 8 Crear listas, en problemas

¿Desea ver una lista de casillas de verificación en su problema?

¿Le gustaría que apareciera como un ingenioso "2 de 5" bar al analizar el problema en una lista?

¡Eso es genial! Puede crear cuadros de verificación interactivos con esta sintaxis:

 - [] Ancho de pantalla (entero) 
- [x] Soporte de trabajador de servicio
- [x] Obtener soporte
- [] Soporte CSS flexbox
- [] Elementos personalizados

Eso es un espacio y un guión y un espacio y un corchete izquierdo y un espacio (o una x) y un corchete cerrado y un espacio y luego algunas palabras.

¡Entonces puedes marcar / desmarcar esas cajas! Por alguna razón, esto me parece una hechicería técnica. ¡Puedes marcar las casillas! ¡Y actualiza el texto subyacente!

¿Qué pensarán de ellos a continuación?

Ah, y si tiene este problema en una placa de proyecto, también mostrará el progreso allí:

Si no sabes de lo que estoy hablando cuando digo "en una pizarra de proyectos", entonces te espera una delicia más adelante en la página.

Como, 2 cm más abajo en la página.

# 9 Tableros de proyectos en GitHub

Siempre he usado a Jira para grandes proyectos. Y para proyectos en solitario siempre he usado Trello. Me gustan bastante los dos.

Cuando supe hace unas semanas que GitHub tiene su propia oferta, justo en la pestaña Proyectos de mi repositorio, pensé en replicar una serie de tareas que ya tenía a punto de ebullición en Trello.

Ninguno de ellos es gracioso

Y aquí está lo mismo en un proyecto de GitHub:

Tus ojos se ajustan a la falta de contraste con el tiempo

Por el bien de la velocidad, agregué todo lo anterior como 'notas', lo que significa que no son problemas reales de GitHub.

Pero el poder de administrar sus tareas en GitHub es que está integrado con el resto del repositorio, por lo que probablemente quiera agregar problemas existentes del repositorio a la pizarra.

Puede hacer clic en Agregar tarjetas arriba en la parte superior derecha y encontrar las cosas que desea agregar. Aquí la sintaxis de búsqueda especial es útil, por ejemplo, escriba is:pr is:open y ahora puede arrastrar cualquier PRs abierto en el tablero, o label:bug si quiere aplastar algunos errores.

O puede convertir notas existentes a problemas.

O, por último, desde la pantalla de un problema existente, agréguela a un proyecto en el panel derecho.

Ingresará en una lista de triaje en esa placa de proyecto para que pueda decidir en qué columna colocarla.

Hay un gran beneficio (enorme) al tener su definición de 'tarea' en el mismo repositorio que el código que implementa esa tarea. Significa que dentro de unos años se puede culpar a alguien por una línea de código y encontrar el camino de regreso a la lógica original detrás de la tarea que resultó en ese código, sin necesidad de ir y rastrearlo en Jira / Trello / en otro lugar.

Las desventajas

He estado probando hacer todas las tareas en GitHub en lugar de Jira durante las últimas tres semanas (en un proyecto más pequeño que es algo así como el estilo Kanban) y me está gustando hasta ahora.

Pero no me puedo imaginar usarlo en un proyecto de scrum en el que quiero hacer una estimación adecuada y calcular la velocidad y todas esas cosas buenas.

La buena noticia es que hay tan pocas "características" de los proyectos de GitHub que no le tomará mucho tiempo evaluar si es algo a lo que puede cambiar. Así que pruébalo, mira lo que piensas.

FWIW, he oído hablar de ZenHub y lo abrí hace 10 minutos por primera vez. Extiende efectivamente GitHub para que pueda estimar sus problemas y crear épicas y dependencias. También hay gráficos de velocidad y burndown; parece que podría ser lo mejor de la tierra.

Lectura adicional: Ayuda de GitHub en Proyectos .

# 10 GitHub wiki

Para una colección no estructurada de páginas, al igual que Wikipedia, la oferta Wiki de GitHub (a la que en lo sucesivo me referiré como Gwiki) es excelente.

Para una colección estructurada de páginas, por ejemplo, su documentación, no tanto. No hay forma de decir "esta página es hija de esa página", o tener cosas bonitas como los botones "Siguiente sección" y "Sección anterior". Y Hansel y Gretel estarían jodidos, porque no hay pan rallado.

(Nota al margen, ¿has leído esa historia? Es brutal. Los dos niños imbéciles matan a la pobre y hambrienta anciana quemándola hasta la muerte en su propio horno . Sin duda, la dejé limpiar el desastre. Creo que esta es la razón por la cual estos jóvenes los días son tan extremadamente sensibles, las historias para dormir hoy en día no contienen suficiente violencia).

Continuando – para dar un giro a Gwiki, ingresé algunas páginas de los documentos de NodeJS como páginas wiki, luego creé una barra lateral personalizada para poder emular tener alguna estructura real. La barra lateral está ahí en todo momento, aunque no resalta la página en la que se encuentra actualmente.

Los enlaces deben mantenerse manualmente, pero sobre todo, creo que funcionaría bien. Eche un vistazo si siente la necesidad.

No va a competir con algo como GitBook (eso es lo que usan los documentos de Redux ) o un sitio web a medida. Pero es un sólido 80% y está todo ahí en su repositorio.

Soy un fan.

Mi sugerencia: si ha superado un solo archivo README.md y desea algunas páginas diferentes para guías de usuario o documentación más detallada, entonces su próxima parada debe ser un Gwiki.

Si comienza a sentir que la falta de estructura / navegación lo está frenando, continúe con otra cosa.

# 11 GitHub Pages (con Jekyll)

Quizás ya sepas que puedes usar GitHub Pages para alojar un sitio estático. Y si no lo hiciste ahora lo haces. Sin embargo, esta sección es específicamente sobre el uso de Jekyll para construir un sitio.

En su forma más simple, GitHub Pages + Jekyll renderizará su README.md en un tema bonito. Por ejemplo, eche un vistazo a mi página Léame de about-github :

Si hago clic en la pestaña 'configuración' de mi sitio en GitHub, active GitHub Pages y elija un tema de Jekyll …

Conseguiré una página con el tema Jekyll :

A partir de este momento, puedo construir un sitio estático completo basado principalmente en los archivos de marcación que son fácilmente editables, convirtiendo esencialmente GitHub en un CMS.

No lo he usado, pero así es como se crean los sitios React y Bootstrap, por lo que no puede ser terrible.

Tenga en cuenta que se requiere que Ruby se ejecute localmente (los usuarios de Windows intercambiarán miradas de complicidad y caminarán en la otra dirección. Los usuarios de macOS dirán "¿Cuál es el problema, dónde estás? Ruby es una plataforma universal! GEMS!")

(También vale la pena agregar aquí que "Contenido o actividad violenta o amenazante" no está permitido en las páginas de GitHub, por lo que no puede alojar su reinicio de Hansel y Gretel).

Mi opinión

Cuanto más buscaba en GitHub Pages + Jekyll (para esta publicación), más parecía que había algo un poco extraño sobre todo.

La idea de 'eliminar toda la complejidad de tener su propio sitio web' es excelente. Pero aún necesita una configuración de compilación para trabajar en ello localmente. Y hay una gran cantidad de comandos CLI para algo tan 'simple'.

Recién revisé las siete páginas en la sección Primeros pasos , y siento que soy la única cosa simple aquí. Y aún no he aprendido la sintaxis simple de "Front Matter" o las entradas y salidas del simple "motor de plantillas líquidas".

Prefiero escribir un sitio web.

Para ser sincero, estoy un poco sorprendido de que Facebook use esto para los documentos de React cuando probablemente podrían crear sus documentos de ayuda con React y preentregar a archivos HTML estáticos en menos de un día.

Todo lo que necesitarían es una forma de consumir sus archivos de rebajas existentes como si provinieran de un CMS.

Me pregunto si…

# 12 Usando GitHub como un CMS

Supongamos que tiene un sitio web con texto, pero no desea almacenar ese texto en el marcado HTML real.

En su lugar, desea almacenar trozos de texto en alguna parte para que puedan ser editados fácilmente por no desarrolladores. Tal vez con alguna forma de control de versiones. Tal vez incluso un proceso de revisión.

Aquí está mi sugerencia: use los archivos de rebajas almacenados en su repositorio para guardar el texto. Luego, tenga un componente en su interfaz que busque esos fragmentos de texto y los muestre en la página.

Soy un chico de React, así que aquí hay un ejemplo de un componente de <Markdown> que, dada la ruta de acceso a cierto markdown, buscará, analizará y presentará como HTML.

(Estoy usando el paquete npm marcado para analizar el marcado en HTML).

Eso apunta a mi repositorio de ejemplo que tiene algunos archivos de rebaja en /text-snippets .

(También podría usar la API de GiHub para obtener los contenidos , pero no estoy seguro de por qué lo haría).

Utilizarías un componente como ese:

Así que ahora GitHub es tu CMS, más o menos, para cualquier fragmento de texto que quieras que contenga.

El ejemplo anterior solo recupera el descuento después de que el componente se haya montado en el navegador. Si quiere un sitio estático, querrá renderizarlo en el servidor.

¡Buenas noticias! No hay nada que le impida obtener todos los archivos de rebajas en el servidor (junto con cualquier estrategia de caché que le funcione). Si sigues ese camino, es posible que desees consultar la API de GitHub para obtener una lista de todos los archivos de rebajas en un directorio.

Ronda de bonificación: ¡herramientas de GitHub!

He usado la extensión Octotree Chrome por un tiempo y lo recomiendo. No de todo corazón, pero lo recomiendo de todos modos.

Te da un panel a la izquierda con una vista en árbol de cualquier repositorio que estés viendo.

De este video aprendí sobre octobox , que hasta ahora parece bastante bueno. Es una bandeja de entrada para tus problemas de GitHub. Eso es todo lo que tengo que decir sobre eso.

Hablando de colores, tomé todas las capturas de pantalla anteriores en el tema de la luz para no asustarte. Pero en realidad, todo lo demás que miro es de temática oscura, ¿por qué debo soportar un GitHub pálido?

Es una combinación de la extensión Stylish Chrome (que puede aplicar temas a cualquier sitio web) y el estilo GitHub Dark . Y para completar el aspecto, el tema oscuro de Chrome DevTools (que está integrado, enciéndalo en la configuración) y Atom One Dark Theme for Chrome.

Bitbucket

Esto no encaja estrictamente en ninguna parte de esta publicación, pero no sería correcto si no di un saludo a Bitbucket.

Hace dos años comencé un proyecto y me pasé medio día evaluando qué anfitrión git era el mejor, y Bitbucket ganó por un margen considerable. Su flujo de revisión de código estaba muy avanzado (esto fue mucho antes de que GitHub tuviera el concepto de asignar un revisor).

GitHub ya se ha puesto al día en el juego de revisión, que es genial. Pero, lamentablemente, no he tenido la oportunidad de utilizar Bitbucket en el último año, tal vez hayan salido adelante de alguna otra manera. Por lo tanto, recomendaría a cualquiera que esté en la posición de elegir un host de git que también visite Bitbucket.

Outro

¡Eso es todo! Espero que haya al menos tres cosas aquí que aún no conocías, y también espero que tengas un buen día.

Editar: hay más consejos en los comentarios; no dude en dejar su propio favorito. Y en serio, realmente espero que tengas un buen día.