pequeño diccionario Dado que los términos Git y otras palabras de moda en programación se usan con mayor frecuencia sin traducción, decidí no traducirlos. Les daré aquí, por razones de orden, una breve traducción de los términos de este artículo con una "decodificación". Tenedor - "tenedor". Básicamente, copias el proyecto tú mismo para refinar algo basado en él. Solicitud de extracción : solicitud de cambio. Enviar sus cambios al repositorio para su revisión (es decir, este código se agregará al proyecto principal solo después de la confirmación por parte del propietario del repositorio o de los compañeros de trabajo) Extraer : “extraer” (a un IDE de su computadora, por ejemplo) un proyecto de GitHub Push : "enviar" un proyecto desde una máquina local a GitHub |
#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.#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:#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.#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:#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:#8 Crea listas de problemas
¿Quieres una casilla de verificación en la descripción de tu problema?- [ ] Ancho de pantalla (entero)
- [x] Soporte del trabajador de servicio
- [x] Obtener soporte
- [] Compatibilidad con CSS flexbox
- [ ] Elementos personalizados
#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.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 :#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 :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.
GO TO FULL VERSION