GithubページでHTTP 404を修正する方法は？
ここ はgh-pagesブランチ上のGitHubリポジトリです。 index.html、CSS、JS、およびピクチャフォルダーがあります。
しかし、 http://roine.github.com/p1 にアクセスすると、HTTP 404が見つかりません。
説明と解決策はありますか？
4か月前にサポートに連絡しましたが、彼らはそれが彼らの側の問題だと言った、彼らは一時的にそれを修正しました（現在のコミットのために）。
今日はもう一度やり直しました
Githubのgh-pagesブランチを削除しました
git Push Origin --delete gh-pagesローカルでgh-pagesブランチを削除しました
git branch -D gh-pagesGitを再初期化しました
git initローカルでブランチを再作成しました
git branch gh-pagesGh-pagesブランチをgithubにプッシュしました
git Push Origin gh-pages
正常に動作し、最終的にページ上のファイルを更新できます。
すべてのファイルを1回だけコミットしました。空のコミットをプッシュし、ページを更新しましたが、動作しました。
git commit --allow-empty -m "Trigger rebuild"
git Push
私の場合、名前が_（_cssや_jsなど）で始まるフォルダーがありましたが、GH PagesはJekyll処理ルールに従ってこれらを無視します。 Jekyllを使用しない場合、回避策は.nojekyllという名前のファイルをルートディレクトリに配置することです。
私はすべてのトリックを行いました ここ on My ForkGithub Page しかし、それは404 'を続けました。
最終的に、私のブラウザは 10分のキャッシュ をウェブ上に置く前にほとんど保持しないことがわかりました。
/index.htmlをURLの最後に追加するだけで、ケースが表示され解決されました。
https://username.github.io/ index.html
gh-pagesブランチでレポをフォークした後、同じ問題が発生しました。フォークのindex.htmlブランチに新しいコミット（gh-pagesの空白のみ）をプッシュするだけで修正できました。
まだ行っていない場合は、GitHubページの設定タブでJekyllテーマを選択します。どうやら Jekyllを使用していない場合でもこれが必要です Pagesサイトに。
私のページも404を続けました。サポートに連絡すると、URLは大文字と小文字が区別されることが指摘されました。私の問題を解決しました。
私の場合8/Aug/2017
- ユーザーページが https://github.com/mgravell の場合、リポジトリ名はmgravell.github.ioでなければなりません
ルートの下に、ファイル
index.htmlを作成しますルートの下に、フォルダーを作成します
docs、ファイルを作成しますCNAMEの下にdocs（注：NO .txtなどの拡張子、ファイルシステムに拡張子が表示されていることを確認してください）gh-pagesブランチはオプション、masterブランチで十分です
more：ここで公式ドキュメントを確認してください： https://help.github.com/articles/configuring-a-publishing-source-for -github-pages /
約10分から1時間待ちます。それでも動作しない場合は、githubに連絡してください。通常、彼らの最後の問題です。ただし、急いでいる場合は、「？」を追加して開くことができます。 URLの最後の疑問符。リソースを検索するクエリを強制します。このような：
構造が正しいことが確実な場合は、空のコミットをプッシュするか、index.htmlファイルをいくらかのスペースで更新するだけで機能します！
Index.htmlファイルの先頭に次を追加します
<!DOCTYPE html>
私の場合、上記の提案はすべて正しかった。マークダウンファイルがあり、正しいように見えても、404を返すページはほとんどありませんが、ほとんどのページは動作していました。これらのページで修正されたのは次のとおりです。
- 1ページに、
UTF-8の一部ではないいくつかの特殊文字がありました。それが、GitHubページがそれらをレンダリングできなかった理由だと思います。これらの文字を更新/削除し、新しいコミットをプッシュすると修正されました。 - 別のページで、タイトルを囲むアポストロフィ
'があることがわかりました。それらを削除すると、ページのコンテンツが正常に表示され始めました
Index/htmlファイルの変更などの手順を再度実行するコンピューター上の「username.github.io」フォルダーを削除することで、サイトを機能させました。
私の間違い（私は思う）私は最初に「 https://github.com/username/username.github.io。git "の代わりに https://github.com/username/username.github.io （「.git」なし）
私の場合、プロジェクトの設定に移動してgithubページを有効にする必要がありました。デフォルトはオフです
すべてが正しく見えても404が表示された場合は、https/httpを切り替えてみてください
元の質問のURLが間違っています。通常、レポの設定を確認し、生成されたサイトの正しいURLを見つけることができます。
しかし、私はすべてが正しくセットアップされており、設定ページにそれが公開されたと書かれていて、それでも404を見ました。
@Rohit Sutharのコメントをありがとう（そのコメントはhttpsを使用することでしたが）、私はURLをhttpに変更し、それが機能したので、httpsも機能しました。
私の場合、URLはかなり長いものでした。だから、私は制限があると思います。私はそれを自分のカスタムサブドメインに入れて、それが機能しました。
この問題が現れる前にドメインをバインドしました。ブランチgh-pagesをコミットしてプッシュし、問題を解決しました。新しいコミットにより、jekyllはページを再構築します。
私は同じ問題を抱えていた..非常に奇妙な問題.. titleの後にHTMLにスペースがあった
> <title>
>
> <script>
修正、スペースを削除した後
> <title>
> <script>
リポジトリの設定セクションに移動し、ソースセクションでmasterブランチを選択し、ページを更新したら[保存]ボタンをクリックすると、ページのリンクが表示されます。
私もこの問題（404）に直面し、根本的な原因は私のファイルの名前がINDEX.mdであったことです。私はWindowsで開発していて、ローカルのJekyllサイトは機能していました（Windowsはデフォルトで大文字と小文字を区別しないファイル名を扱うため）。 Githubにプッシュしても、機能しませんでした。 INDEX.mdの名前をindex.mdに変更すると、うまくいきました。
さらに別のシナリオ：
<orgname>.github.ioという名前のリポジトリを持つ組織ページ（プロジェクトページではない）を使用するmasterブランチのマークアップとしてのソースドキュメント（asciidoc）- Travis CIは
masterからソースdocファイルをプルし、生成されたhtmlファイルをgh-pagesブランチにプッシュします
gh-pagesブランチは、生成されたhtmlページで更新されます。 GitHub Environmentタブは、組織ページへのリンクを提供します。クリックすると404になります。
https://help.github.com/articles/configuring-a-publishing-source-for-github-pages/
このタイプのリポジトリ名を持つユーザーおよび組織ページは、
masterブランチからのみ公開されます
これを正しく理解していれば、UserサイトではなくOrganizationまたはProjectサイトを作成している場合、GitHub Pagesはgh-pagesブランチから公開されません。
リポジトリの名前を変更してProjectサイトではなくOrganizationサイトにし、gh-pagesブランチを期待どおりに公開しました。
プライベートリポジトリで、gh-pagesブランチを最初にgithubに追加してプッシュしたとき、git-pagesブランチが公開されることを示すようにgithubページの設定が自動的に変更されましたが、github.ioに緑色または青色のバーはありませんurlおよびカスタムドメインオプションなし。
ソースをマスターに切り替え、すぐにソースをghページに切り替えてから、公開されたURLを含む緑色のバーで実際に更新しました。
また、 GitHubページは現在Git LFSをサポートしていません 。そのため、Git LFSでコミットされたGitHubページに画像（または他のバイナリアセット）がある場合、それらのファイルで404が見つかりません。
これは、Doxygenまたは同様のツールで生成されたドキュメントで非常に一般的です。
この場合の解決策は、Git LFSでこれらのファイルをコミットしないことです。