Hemos buscando por todo internet para brindarte la solución para tu duda, en caso de alguna inquietud puedes dejar tu pregunta y te contestaremos sin falta, porque estamos para servirte.
Solución:
Después de investigar un poco, encontré esta solución:
[the real relative root of any fork](/../../)
Siempre apunta a la rama predeterminada. Para mí está bien, así que depende de ti
PD
Con tal truco también puedes acceder a las siguientes habilidades:
[test](/../../tree/test) – enlace a otra rama
[doc/readme.md](/../../edit/master/doc/readme.md) – abrir en editor
[doc/readme.md](/../../delete/master/doc/readme.md) – pedir borrar el archivo
[doc/readme.md](/../../commits/master/doc/readme.md) – historia
[doc/readme.md](/../../blame/master/doc/readme.md) – modo de culpa
[doc/readme.md](/../../raw/master/doc/readme.md) – modo crudo (redirigirá)
[doc/](/../../new/master/doc/) – pedir crear un nuevo archivo
[doc/](/../../upload/master/doc/) – pedir subir archivo
[find](/../../find/test) – encontrar archivo
Puede vincular directamente al archivo (../README.md), o simplemente use una URL absoluta completa para vincular directamente a la raíz del repositorio: https://github.com/UserName/RepoName
El uso de enlaces relativos no funciona tan bien en GitHub. Observe la diferencia entre las siguientes dos URL:
https://github.com/UserName/RepoName/tree/master/somedir
https://github.com/UserName/RepoName/blob/master/somedir/somefile
Observe que el primero apunta a un directorio y el segundo apunta a un archivo. Sin embargo, después del “RepoName” tenemos uno de tree (para un directorio) o blob para un archivo. Por lo tanto, los vínculos relativos entre los dos no funcionarán correctamente. En GitHub, no puede utilizar enlaces relativos para enlazar entre un archivo y un directorio. Sin embargo, puede vincular entre dos archivos (ya que ambas URL contienen blob). Por lo tanto, si desea vincular desde somefile de regreso README.md en la raíz, podrías hacer:
[README](../README.md)
Eso le daría la URL:
https://github.com/UserName/RepoName/blob/master/somedir/../README.md
que se normalizaría a
https://github.com/UserName/RepoName/blob/master/README.md
Sin embargo, si solo desea apuntar a la raíz de su Repo (o cualquier otro directorio), probablemente sea mejor usar una URL completa. Después de todo, si alguien ha descargado su repositorio y está viendo la fuente localmente, la URL relativa a la raíz del repositorio será diferente a cuando se ve el archivo en GitHub. En ese caso, probablemente quieras apuntarlos a GitHub de todos modos. Por lo tanto, debe utilizar:
[root](https://github.com/UserName/RepoName)
Otra ventaja de eso es que si su documentación alguna vez se publica en otro lugar (tal vez un servicio de alojamiento de documentación), el enlace seguirá apuntando al repositorio de GitHub, no a una página aleatoria en el servicio de alojamiento. Después de todo, no es probable que el archivo README en la raíz de su proyecto se incluya con el contenido del docs/ dir en dicho servicio de alojamiento.
Quizás sería útil comprender cómo presumiblemente funciona el esquema de URL de GitHub. Digo “presumiblemente” porque no tengo conocimiento interno, solo una comprensión general de cómo se diseñan generalmente estos tipos de sistemas.
GitHub no ofrece archivos planos. Más bien, su servidor está desarmando la URL y usa las diversas piezas para devolver la respuesta adecuada. La estructura de la URL se parece a esto:
https://github.com/////
El username, repository name, resource type, y branch son formas bastante arbitrarias y justas de GitHub para asegurarse de que están extrayendo información de la ubicación correcta.
El resource type importa, ya que es probable que no extraigan archivos de un árbol de trabajo. Más bien, están extrayendo los listados de archivos / directorios directamente desde el propio Repo a través de un nivel inferior. En ese caso, obtener un archivo es muy diferente a obtener un listado de directorio y requiere una ruta de código diferente. Por lo tanto, no puede solicitar un blob (archivo) con unresource path que apunta a un árbol (directorio) o viceversa. El servidor se confunde y devuelve un error.
El punto es que el servidor de GitHub funciona con un conjunto de reglas ligeramente diferente. Puede utilizar URL relativas para moverse dentro de la resource path parte de la URL, pero una vez que cambie la resource type en el resource path parte de la URL, entonces todo el esquema de GitHub se rompe si no cambia también el resource type en la URL. Sin embargo, los navegadores (o HTML o Markdown) no tienen conocimiento sobre eso y las URL relativas no compensan eso. Por lo tanto, no puede usar URL relativas de manera confiable para moverse dentro de un repositorio de GitHub a menos que comprenda todas las sutilezas. A veces es mejor usar enlaces absolutos.
Te mostramos reseñas y valoraciones
Tienes la opción de amparar nuestra ocupación poniendo un comentario o puntuándolo te damos las gracias.