(私はそれがどんなフォークでも機能する必要があります)
したがって、ルートにあるファイルへのリンクを提供する唯一の方法のように見えます。
the [Root](/README.md)
または
the [Root](../README.md)
(例えば/doc/README.mdにある場合)
同時に、ファイルを参照せずに任意のフォルダーを参照できます
the [Doc](/doc)
しかし、ルートフォルダーへのリンクを配置しようとすると、次のようになります。
the [real root](/)
the [real root](../)
私はそのようなリンクを持っています
https://github.com/UserName/RepoName/blob/master
とは異なり
https://github.com/UserName/RepoName/blob/master/ doc
404を参照
したがって、ルートでREADME.mdを参照したくない場合(私はそれをまったく持っていない可能性があります)
いくつかの研究の後、私はそのような解決策を見つけました:
[the real relative root of any fork](/../../)
常にデフォルトのブランチを指します。私にとってはそれでいいので、あなた次第です
PS
このようなトリックを使用すると、次の能力にもアクセスできます。
[test](/../../tree/test)
-別のブランチへのリンク
[doc/readme.md](/../../edit/master/doc/readme.md)
-エディターで開く
[doc/readme.md](/../../delete/master/doc/readme.md)
-ファイルの削除を要求
[doc/readme.md](/../../commits/master/doc/readme.md)
-履歴
[doc/readme.md](/../../blame/master/doc/readme.md)
-非難モード
[doc/readme.md](/../../raw/master/doc/readme.md)
-行モード(リダイレクトされます)
[doc/](/../../new/master/doc/)
-新しいファイルの作成を要求します
[doc/](/../../upload/master/doc/)
-ファイルのアップロードを要求
[find](/../../find/test)
-ファイルを検索
ファイル(../README.md
)に直接リンクするか、完全な絶対URLを使用してリポジトリのルートに直接リンクすることができます:https://github.com/UserName/RepoName
相対リンクを使用しても、GitHubではうまく機能しません。次の2つのURLの違いに注意してください。
https://github.com/UserName/RepoName/tree/master/somedir
https://github.com/UserName/RepoName/blob/master/somedir/somefile
1つ目はディレクトリを指し、2つ目はファイルを指していることに注意してください。ただし、「RepoName」の後には、tree
(ディレクトリの場合)またはblob
のいずれかがファイル用に表示されます。したがって、2つの間の相対リンクは正しく機能しません。 GitHubでは、ファイルとディレクトリ間のリンクに相対リンクを使用することはできません。ただし、2つのファイル間をリンクできます(両方のURLにblob
が含まれているため)。したがって、somefile
からルートのREADME.md
にリンクを戻す場合は、次のようにします。
[README](../README.md)
それはあなたにURLを与えるでしょう:
https://github.com/UserName/RepoName/blob/master/somedir/../README.md
これは正規化されます
https://github.com/UserName/RepoName/blob/master/README.md
ただし、リポジトリのルート(またはその他のディレクトリ)をポイントするだけの場合は、完全なURLを使用することをお勧めします。結局のところ、誰かがリポジトリをダウンロードしてローカルでソースを表示している場合、リポジトリルートへの相対URLは、GitHubでファイルを表示するときとは異なります。その場合は、おそらくそれらをGitHubにポイントすることをお勧めします。したがって、以下を使用する必要があります。
[root](https://github.com/UserName/RepoName)
そのもう1つの利点は、ドキュメントが他の場所(おそらくドキュメントホスティングサービス)で公開された場合でも、リンクはホスティングサービスのランダムなページではなく、GitHubリポジトリを指すことです。結局のところ、プロジェクトのルートにあるREADMEは、上記のホスティングサービスのdocs/
dirのコンテンツに含まれる可能性はほとんどありません。
おそらく、GitHubのURLスキームがおそらくどのように機能するかを理解するのに役立つでしょう。私は「おそらく」と言います。私は内部の知識がなく、これらのタイプのシステムが一般的にどのように設計されているかについての一般的な理解があるだけです。
GitHubはフラットファイルを提供していません。むしろ、彼らのサーバーはURLを分解し、さまざまな部分を使用して適切な応答を返します。 URL構造は次のようになります。
https://github.com/<username>/<repository name>/<resource type>/<branch>/<resource path>
username
、repository name
、resource type
、およびbranch
はかなり恣意的であり、GitHubが正しい場所から情報を確実に取得する方法にすぎません。
resource type
は、作業ツリーからファイルをプルしていない可能性が高いため、重要です。むしろ、それらは、ファイル/ディレクトリのリストを、レポ自体から直接、より低いレベルまで引き出しています。その場合、ファイルを取得することは、ディレクトリリストを取得することとは大きく異なり、異なるコードパスが必要です。したがって、ツリー(ディレクトリ)を指すaresource path
を使用してBLOB(ファイル)を要求したり、その逆を要求したりすることはできません。サーバーが混乱し、エラーを返します。
重要なのは、GitHubのサーバーが少し異なるルールのセットで動作することです。相対URLを使用してURLのresource path
部分内を移動できますが、URLのresource type
部分のresource path
を変更すると、GitHubのスキーム全体が壊れます。 URLのresource type
も変更しないでください。ただし、ブラウザ(またはHTMLまたはMarkdown)はそのことを認識しておらず、相対URLはそれを補正しません。したがって、すべての機微を理解していない限り、GitHubリポジトリ内を移動するために相対URLを確実に使用することはできません。絶対リンクを使用する方が良い場合もあります。