12 características sorprendentes de GitHub

Por mi vida, no se me ocurre ninguna introducción, así que...

#1 Edición de código en GitHub.com

Empezaré con lo que creo que todo el mundo ya sabe (aunque yo personalmente no tenía ni idea hace una semana). Al visualizar cualquier archivo de texto en GitHub, en cualquier repositorio, puedes ver un pequeño lápiz en la parte superior derecha. Si hace clic en él, puede editar este archivo. Una vez completado, haga clic en Proponer cambio de archivo y GitHub creará una bifurcación y una solicitud de extracción. Increíble, ¿no? ¡Él mismo crea el tenedor! No es necesario bifurcar y cargar el código usted mismo, realizar cambios localmente y enviarlo de regreso a GitHub con una solicitud de extracción. Muy conveniente si necesita realizar ediciones mínimas. no es una solicitud de extracción real

#2 Insertar imágenes

Las descripciones de los problemas no se limitan solo a comentarios de texto. ¿Sabías que puedes pegar imágenes directamente desde el portapapeles? Cuando lo pegue, lo verá cargado (en la nube, sin duda) y convertido en marcado para mostrar la imagen. ¡Agraciado!

#3 Formato de código

Si necesitas escribir un bloque de código, comienza con tres comillas invertidas y GitHub intentará adivinar en qué lenguaje de programación estás escribiendo. Pero si publica un fragmento de código en un lenguaje de programación como Vue, Typecript o JSX, puede especificar explícitamente el idioma para que el resaltado de sintaxis sea correcto. Observe el ```jsx en la primera línea: ...asegurando la visualización correcta del fragmento de código: (Por cierto, esto también se aplica a Gist. Si especifica la extensión .jsf para un gist, la sintaxis JSF se resaltará). Aquí hay una lista de todas las sintaxis admitidas .

#4 Cerrar problemas usando “palabras mágicas” en Pull Requests

Supongamos que crea una solicitud de extracción que soluciona el problema n.° 234. Puede insertar el texto "soluciona el problema n.º 234" en la descripción de su solicitud (o en cualquier lugar de cualquier comentario de solicitud de cambio). Después de esto, fusionar la solicitud de extracción cerrará "automáticamente" el problema. Genial, ¿no? Aquí hay más información sobre esto en la documentación .

#5 Enlace a comentarios

¿Alguna vez has necesitado crear un enlace a un comentario específico y no sabías cómo? Esos días ya pasaron porque te contaré un secreto: para crear un enlace a un comentario, simplemente haz clic en la fecha/hora al lado del título. ¡Mira, gaearon ahora tiene una foto!

#6 Enlace de código

Entonces desea crear un enlace a una línea de código específica. En este caso, intente esto: haga clic en el número de línea al lado del código deseado en el archivo abierto. Vaya, ¿ves? La URL ha cambiado, ¡el número de línea ahora es visible en ella! Si mantiene presionada la tecla MAYÚS y hace clic en otro número de línea, ¡listo! – La URL cambiará nuevamente y se resaltará el rango de filas. Esta URL ahora apuntará a este archivo y este rango de líneas. Pero espera, apunta al hilo actual. ¿Qué pasa si el archivo cambia? Probablemente necesites, en este caso, un enlace permanente al archivo en su estado actual. Soy muy vago, así que tomé una captura de pantalla de todo lo anterior: Por cierto, sobre las URL...

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

La navegación por GitHub mediante la interfaz de usuario está organizada de forma muy cómoda. Pero a veces, para llegar a una ubicación específica, es más rápido simplemente escribirla en la URL. Por ejemplo, si quiero ir a una rama en la que estoy trabajando y ver cómo se compara con la maestra, simplemente puedo escribir /compare/branchname después del nombre del repositorio. Esto me llevará a la página de diferencias de esa rama: Pero estas son diferencias con la rama maestra, pero si trabajé con la rama de integración antes, puedo ingresar /compare/integration-branch...my-branch en la URL Para los amantes de las teclas de acceso rápido: CTRL+L o CMD+L mueve el cursor a la barra de URL (al menos en los navegadores Chrome y Firefox). Esto, combinado con el autocompletado del navegador, hace que la navegación entre ramas sea mucho más fácil. Consejo profesional: use las flechas para navegar a través de las sugerencias de autocompletar de Chrome y presione MAYÚS+SUPR para eliminar elementos del historial (por ejemplo, después de fusionar una rama). (No sé si sería más fácil leer estas teclas de método abreviado si les pongo un espacio, como SHIFT + SUPR. Pero técnicamente “+” no es parte de ellas, así que no me gusta esta opción. Es Por cosas como ésta no duermo por las noches, Rhonda.)

#8 Crea listas de problemas

¿Quieres una casilla de verificación en la descripción de tu problema? ¿Y desea que aparezca una barra ingeniosa como “2 de 5” cuando vea un problema de la lista? ¡Ningún problema! Puede crear casillas de verificación interactivas utilizando la siguiente sintaxis:

• [ ] Ancho de pantalla (entero)
• [x] Soporte del trabajador de servicio
• [x] Obtener soporte
• [] Compatibilidad con CSS flexbox
• [ ] Elementos personalizados

Sintaxis: espacio, guión, espacio, corchete de apertura, espacio (o x), corchete de cierre, espacio y algunas palabras. Después de eso, ¡puedes marcar o desmarcar estos botones! Por alguna razón, esto me parece una especie de magia técnica. ¡Puedes marcar las casillas! ¡Y al mismo tiempo cambia el texto original! Da miedo pensar qué se les ocurrirá a continuación. Ah, y si este problema está en el panel del proyecto, entonces el progreso también se mostrará allí: Si no comprende lo que quiero decir con "panel de proyecto", lea a continuación. Sólo un par de centímetros más abajo en esta página.

#9 Paneles de proyecto en GitHub

Para proyectos grandes siempre he usado Jira. Y para mis proyectos personales siempre he usado Trello. Realmente me gustan ambas herramientas. Cuando hace unas semanas supe que GitHub ofrecía su propia opción, directamente en la pestaña Proyectos del repositorio, pensé que tendría sentido duplicar el conjunto de tareas con las que ya trabajo en Trello. No hay nada gracioso aquí y ahora lo mismo en el proyecto GitHub: Poco a poco tus ojos se irán acostumbrando a la imagen de bajo contraste. En aras de la velocidad, agregué todo lo anterior como notas, lo que significa que no son problemas "reales" de GitHub. Pero el poder de la gestión de problemas en GitHub radica en su integración con el resto del repositorio, por lo que probablemente sea mejor agregar problemas existentes desde el repositorio al panel. Haga clic en Agregar tarjetas en la esquina superior derecha y busque lo que desea agregar. Aquí es donde resulta útil una sintaxis de búsqueda especial : por ejemplo, escriba is:pr is:open y puede arrastrar cualquier solicitud de extracción abierta al panel, o etiqueta:bug si necesita corregir algún error. También puede convertir notas existentes en ediciones. Y finalmente, desde el formulario de problema existente, agréguelo al proyecto en el panel derecho. Irá a la lista de clasificación de ese panel de proyecto, para que pueda elegir en qué columna colocarlo. Cuando la descripción de una “tarea” está en el mismo repositorio que el código que implementa esta tarea, es muy (muy) conveniente. Esto significa que dentro de muchos años, podrás ejecutar git listening en una línea de código y descubrir la totalidad del problema que condujo a esa línea, sin tener que rastrearlo todo en Jira/Trello/otro lugar.

Defectos

Durante las últimas tres semanas he estado experimentando haciendo todo en GitHub en lugar de Jira (en un proyecto pequeño, una especie de estilo Kanban) y me encanta. Pero no puedo imaginar esto para un proyecto Scrum donde la velocidad de desarrollo y cosas similares deben evaluarse y calcularse adecuadamente. La buena noticia es que los proyectos de GitHub tienen tan pocas "características especiales" que cambiar a otro sistema no llevará mucho tiempo. Así que pruébalo y verás cuánto te gusta. No sé qué tan importante es esto, pero escuché sobre ZenHub y lo abrí por primera vez hace 10 minutos. Es esencialmente una extensión de GitHub donde puedes calificar problemas y crear "épicas" y dependencias. Hay gráficos de velocidad de desarrollo y agotamiento; Parece que es algo asombroso. Lectura adicional: documentación de GitHub sobre proyectos.

#10 Gwiki

Para un conjunto de páginas no estructuradas, como Wikipedia, GitHub Wiki (que de ahora en adelante llamaré Gwiki) es excelente. Para un conjunto estructurado de páginas, por ejemplo, como su documentación, no tanto. No hay forma de indicar que "esta página es hija de aquella", no existen cosas tan convenientes como los botones "Siguiente sección" y "Sección anterior". Hansel y Gretel definitivamente se perderían aquí, porque aquí tampoco hay "migas de pan" (operadores de depuración especiales, aprox. trans.). (Nota del autor: ¿Has leído esta historia? Es simplemente inhumana. Dos jóvenes matones matan a una pobre anciana hambrienta, quemándola viva en su propio horno . Y, por supuesto, dejando un completo desastre que nadie puede entender. Creo que es por eso los jóvenes de hoy en día son muy sensibles (¡los cuentos que se les leen a los niños a la hora de dormir hoy en día no son lo suficientemente crueles!) Continuando, para probar Gwiki de verdad, ingresé algunas páginas de NodeJS como páginas wiki, luego creé una página wiki personalizada. barra lateral para simular la estructura real del sitio. Esta barra lateral siempre está ahí, aunque la página actual no esté resaltada. Los enlaces deberán mantenerse manualmente, pero en general todo funciona bien. Si quieres, puedes echarle un vistazo : Esto difícilmente puede competir con algo como GitBook (que se usa en la documentación de Redux ) o un sitio web personalizado. Pero esto ya es un buen 80% y todo está bien en su repositorio. Sólo soy un fan de esto. Le sugiero que si se le ha quedado pequeño el archivo README.md y necesita varias páginas diferentes para manuales de usuario o documentación más detallada, tiene sentido seguir con Gwiki. Si te molesta la falta de estructura/navegación, pasa a otra cosa.

#11 páginas de GitHub

Quizás ya sepas que GitHub Pages se puede utilizar para alojar un sitio web estático. Y si no lo sabías, ahora lo sabes. Sin embargo, esta sección está dedicada a un tema más específico: usar Jekyll para crear un sitio web. En su forma más simple, GitHub Pages + Jekyll puede representar el archivo README.md usando un tema atractivo. Por ejemplo, eche un vistazo a mi página Léame de about-github : Si hace clic en la pestaña de configuración de este sitio de GitHub, habilite las páginas de GitHub y seleccione el tema Jekyll... Luego nos saldrá una página al estilo del tema Jekyll : Luego puede crear un sitio estático completo basado principalmente en archivos de marcado fácilmente editables, esencialmente convirtiendo a GitHub en un CMS. Aunque en realidad no he usado esto, así es como se construyen los sitios web usando el marco Bootstrap usando React, por lo que no tiene nada de terrible. Observo que Ruby debe estar ejecutándose en la máquina local (los usuarios de Windows aquí intercambiarán miradas comprensivas y se irán en otra dirección, los usuarios de macOS dirán: “¿Cuál es el problema, adónde vas? ¡Ruby es una plataforma universal! También hay GEMS). ¡sistema de administración de paquetes!”) (También vale la pena señalar que "Contenido o comportamiento agresivo o amenazante" no está permitido en las páginas de GitHub, por lo que no podrás publicar tu versión de la historia de Hansel y Gretel allí).

Mi opinión

Cuanto más analizaba la combinación GitHub Pages + Jekyll (para este artículo), más pensaba que la idea olía rara. La idea de "hacer tu propio sitio web con el mínimo esfuerzo" es genial. Pero para trabajar en él aún necesitas la versión actual en la máquina local. Y para algo tan "simple" hay demasiados comandos de línea de comando. Hojeé las siete páginas de la sección Primeros pasos y sentí que lo único simple era yo . Y ni siquiera he descubierto la sintaxis simple de la página principal o los conceptos básicos de un simple "mecanismo de plantillas basado en el lenguaje Liquid". ¡Prefiero escribir un sitio web yo mismo! Para ser honesto, estoy un poco sorprendido de que Facebook esté usando esto para la documentación de React cuando probablemente podrían crear sus páginas del sistema de ayuda usando React y renderizar previamente como archivos HTML estáticos todos los días . Todo lo que necesitan hacer es encontrar una manera de recibir archivos de marcado existentes como si vinieran del CMS. Y si...

#12 Usando GitHub como CMS

Digamos que tenemos un sitio web con algo de texto, pero no queremos almacenar ese texto como formato HTML. En su lugar, nos gustaría almacenar fragmentos de texto en algún lugar que los usuarios que no sean desarrolladores puedan editar fácilmente. Preferiblemente con alguna opción de versionado. Quizás incluso con algún tipo de proceso de revisión por pares. Esto es lo que sugiero: use los archivos de marcado almacenados en el repositorio para almacenar el texto. Y use un componente en el lado del cliente que recupere estos fragmentos de texto y los muestre en la página. Soy fanático de React, así que aquí hay un ejemplo de un componente <Markdown> adecuado que, dada una ruta a un archivo de rebajas, lo extraerá, lo analizará y lo representará como HTML.

class Markdown extends React.Component {
    constructor(props) {
      super(props);

      // Конечно, вам нужно заменить это на свой URL
      this.baseUrl = 'https://raw.githubusercontent.com/davidgilbertson/about-github/master/text-snippets';

      this.state = {
        markdown: '',
      };
    }

    componentDidMount() {
      fetch(`${this.baseUrl}/${this.props.url}`)
        .then(response => response.text())
        .then((markdown) => {
          this.setState({markdown});
        });
    }

    render() {
      return (
        <div dangerouslySetInnerHTML={{__html: marked(this.state.markdown)}} />
      );
    }
}

(Aquí uso el paquete marcado npm para analizar el marcado en HTML) La URL apunta a mi repositorio de ejemplo, que contiene archivos de marcado en el directorio /text-snippets . (También puedes usar la API de GitHub para recuperar contenido , pero dudo que lo necesites). Podrías usar un componente como este:

const Page = () => (
  <div className="page">
    <div className="about-us">
      <Markdown url="about-us.md" />
    </div>

    <div className="disclaimer">
      <p>A very important disclaimer:</p>

      <Markdown url="disclaimers/home-page-disclaimer.md" />
    </div>
  </div>
);

Así que ahora GitHub actúa como, en cierto modo, su CMS para aquellos fragmentos de texto que le gustaría alojar. El ejemplo anterior solo recupera el marcado después de que el componente se carga en el navegador. Si necesita un sitio estático, deberá renderizarlo en el servidor. ¡Buenas noticias! No hay nada que le impida recuperar todos los archivos de marcado en el servidor (usando la estrategia de almacenamiento en caché que desee). Si decide seguir este camino, tiene sentido utilizar la API de GitHub para obtener una lista de todos los archivos de marcado en un directorio. Bonificación: ¡utilidades de GitHub! He estado usando la extensión Octotree Chrome desde hace bastante tiempo y te la recomiendo. No sin reservas, pero aun así lo recomiendo. Muestra un panel a la izquierda con una vista de árbol del repositorio que estás navegando. Y de este vídeo conocí octobox , que también me parece una muy buena utilidad hasta el momento. Esta es la bandeja de entrada para tus problemas de GitHub. Eso es todo lo que necesitas saber sobre él. Hablando de colores, tomé todas las capturas de pantalla anteriores con un tema claro para no asustarte. Pero si prefiero los colores oscuros en todo lo demás, ¿por qué aguantar un GitHub mortalmente pálido? Aquí utilicé una combinación de la extensión Stylish para el navegador Chrome (que puede aplicar temas a cualquier sitio web) y el estilo GitHub Dark . Y para empezar, el tema oscuro de herramientas para desarrolladores de GitHub (integrado, solo necesitas habilitarlo) y el tema Atom One Dark para Chrome.

Bitbucket

Estrictamente hablando, no es del todo apropiado aquí, pero no puedo evitar mencionar Bitbucket. Hace dos años comencé un proyecto y pasé medio día eligiendo el mejor hosting git. Entonces, Bitbucket ganó por un margen significativo. Su proceso de revisión de código está muy por delante de la competencia (esto fue mucho antes de que GitHub tuviera el concepto de revisor). Desde entonces, GitHub también ha recibido críticas. Desafortunadamente, no he tenido la oportunidad de usar Bitbucket durante el último año; tal vez hayan avanzado en algo nuevamente. Por lo tanto, recomiendo que aquellos que son responsables de elegir un servicio de alojamiento Git también presten atención a Bitbucket.

Conclusión

¡Eso es todo! Espero haber podido contarte al menos tres cosas que antes desconocías. Y también espero que hayas pasado un buen rato leyendo mi artículo.