Cómo organizar el historial de un repositorio y buscar mediante GitHub
Aquí se explica cómo usar los filtros, el comando blame y la vinculación cruzada para organizar el historial de un repositorio y buscar en él.
Póngase en el lugar de un desarrollador que acaba de unirse a un proyecto de gran tamaño. Alguien acaba de comunicar un nuevo error relacionado con la barra lateral de la aplicación web y se lo han asignado para que lo corrija. Ya ha leído el informe varias veces y ha comprendido el problema que se describe, así que ahora debe pensar en cómo corregirlo.
Como nuevo miembro del equipo, todavía no está familiarizado con el código base. Además, no ha estado presente en las discusiones de planeación, las revisiones de código ni en ninguna otra cosa que pueda proporcionarle el contexto que necesita para iniciar la implementación. Primero necesita adquirir ese conocimiento de fondo para determinar mejor la corrección adecuada.
Búsqueda en GitHub
Aunque no estuviera presente en los eventos que dieron lugar a la implementación de la barra lateral, muchos de esos eventos residen en el historial del proyecto. La búsqueda de "barra lateral" en el repositorio del proyecto le proporciona un punto de partida.
Hay dos métodos de búsqueda disponibles en GitHub: la búsqueda global de la parte superior de la página y la búsqueda con ámbito disponible en determinadas pestañas del repositorio. Ambas admiten la misma sintaxis y funcionan de la misma manera, pero con algunas diferencias fundamentales.
Búsqueda global
La búsqueda global permite usar la sintaxis de búsqueda completa para buscar en todo GitHub.
Los resultados de la búsqueda son integrales e incluyen todo: el código, los problemas, Marketplace e incluso los usuarios. Esta es la mejor manera de buscar menciones de términos clave en varios tipos de resultados y repositorios.
Nota:
La cláusula de filtro is:pr filtra los problemas devueltos desde el almacén de problemas o solicitudes de incorporación de cambios. Algunas cláusulas de filtro, como is:pr, solo son admitidas por determinados proveedores de búsquedas y son pasadas por alto por otros. Por ejemplo, el proveedor de búsquedas de código no admite esa cláusula, por lo que la omite y devuelve los mismos resultados de código en cualquier caso.
En este escenario, el uso de la búsqueda global cuyo ámbito es el repositorio actual es una buena manera de encontrar código y confirmaciones que mencionen el término "barra lateral". También es probable que la búsqueda ofrezca resultados sobre problemas y solicitudes de incorporación de cambios, aunque no son tan fáciles de filtrar en la vista de resultados de la búsqueda global.
Para crear una búsqueda global compleja, pruebe la búsqueda avanzada.
Búsqueda de contexto
Las búsquedas de contexto están disponibles en determinadas pestañas, como Problemas y Solicitudes de incorporación de cambios. Estas búsquedas tienen como ámbito el repositorio actual y solo devuelven resultados de ese tipo. La ventaja del ámbito es que permite a la interfaz de usuario exponer filtros conocidos de un tipo específico, como autores, etiquetas, proyectos, etc.
El uso de la búsqueda de contexto es la opción preferida cuando se busca algo en el repositorio actual. En este escenario, es una buena manera de encontrar resultados de búsqueda que mencionen "barra lateral", que luego se podrían refinar fácilmente mediante las listas desplegables de filtros.
Uso de filtros de búsqueda
Hay un número infinito de formas de buscar con la sintaxis de búsqueda completa, aunque la mayoría de las búsquedas solo usan unos cuantos filtros comunes. Aunque suelen estar disponibles en las listas desplegables de búsqueda de contexto, a veces resulta más cómodo escribirlos directamente.
Estas son algunas consultas de filtro de ejemplo:
| Consulta | Explicación |
|---|---|
is:open is:issue assignee:@me |
Problemas abiertos asignados al usuario actual (@me) |
is:closed is:pr author:contoso |
Solicitudes de incorporación de cambios cerradas creadas por @contoso |
is:pr sidebar in:comments |
Solicitudes de incorporación de cambios en las que se menciona "barra lateral" en los comentarios |
is:open is:issue label:bug -linked:pr |
Problemas abiertos etiquetados como errores que no tienen ninguna solicitud de incorporación de cambios vinculada |
Más información para Entender la sintaxis de búsqueda
¿Qué es git blame?
A pesar de su ominoso nombre (culpabilidad), git blame es un comando que muestra el historial de confirmaciones de un archivo. Facilita la tarea de ver quién ha realizado qué cambios y cuándo. Eso facilita muchísimo el seguimiento de otras personas que han trabajado en un archivo para buscar su aportación o participación.
Nota:
Algunos sistemas de Git usan el alias git praise para git blame a fin de evitar la implicación de juicio.
Blame en GitHub
GitHub extiende la funcionalidad básica de git blame con una interfaz de usuario más sólida.
En este escenario, hay varias maneras de llegar a esta vista. Puede que haya encontrado algún código de barra lateral en la búsqueda global y haya seleccionado la opción Responsabilizar para ver quién ha trabajado en él por última vez, o puede que haya encontrado una solicitud de cambios y le haya realizado un seguimiento hasta la última confirmación que parece estar relacionada con la descripción del error. Como quiera que haya llegado hasta aquí, la vista de Blame es una manera eficaz de encontrar un experto en la tarea en cuestión.
Vinculación cruzada de problemas, confirmaciones, etc.
Parte de lo que hace que GitHub sea excelente para proyectos de software de colaboración es su compatibilidad con la vinculación de fragmentos de información dispares. Parte de esto se realiza automáticamente, como cuando se crea una solicitud de incorporación de cambios a partir de una serie de confirmaciones en una bifurcación. Otras veces, puede usar la interfaz para vincular manualmente solicitudes de incorporación de cambios o proyectos a problemas mediante las opciones de lista desplegable.
Referencias de vínculos automáticos
Para que la vinculación cruzada de diferentes elementos en el proyecto sea aún más fácil, GitHub ofrece una sintaxis abreviada. Por ejemplo, si deja un comentario como Duplicate of #8, GitHub reconoce que ese #8 es un problema y crea el vínculo adecuado de forma automática.
GitHub también vincula las confirmaciones automáticamente si se pegan los primeros siete o más caracteres de su identificador.
En este escenario, estos vínculos podrían resultar muy valiosos para acelerar si alguien hubiera pensado dejar el contexto por adelantado. Por ejemplo, el estado actual de la barra lateral puede haber tenido algunos problemas conocidos relacionados con una dependencia de JavaScript. Si el problema con esa dependencia se ha tratado en otro problema en el que no se ha mencionado "barra lateral" de forma explícita, sería difícil de encontrar. Pero si alguien hubiera pensado por adelantado en vincular el problema en la discusión, podría ahorrarle mucho tiempo ahora. Tenga esto en cuenta la siguiente vez que esté documentando problemas y solicitudes de incorporación de cambios.
Más información sobre Referencias y direcciones URL autovinculadas.
Inclusión de usuarios con @mention
Además de vincular problemas y confirmaciones, suele ser útil asociar a otras personas a las discusiones. La manera más sencilla de hacerlo es usar @mention. Este tipo de mención notifica al usuario mencionado para que pueda participar en la discusión. También es una buena manera de identificar a las personas asociadas a los problemas mucho tiempo después de que se hayan cerrado.
