GitHubページのSphinxドキュメント

GitHub Pagesは、a）ビルトインエディタを使用して作成されたページを表示し、b）Jekyllブログを生成し、c）任意のドメインにhtmlファイルを表示できる、とてもクールな統合失調症です。
最後の画像では、彼女はSphinxを使用して書かれたドキュメントを投稿することに興味を持っています。

技術的には、いずれにしても、 gh-pagesブランチが作成され（ を除く ）、そこからコンテンツが表示されます。
したがって、プロジェクトは1つのリポジトリであり、そのドキュメントは別のリポジトリであり、それらを混在させることは意味がありません。
masterドキュメントリポジトリでは、ソースをReStructuredText形式で保存し、構成ファイルを変更履歴とともに保存します。 gh-pages履歴が無意味であるだけでなく、論理的にこのブランチはmasterと並行して存在します。 次のスクリプトを作成して、このような前提から進めました。

 #!/bin/sh shopt -s extglob dotglob CURR_DIR="$(pwd)" TMP_DIR="$CURR_DIR"-gh-pages sh build.sh rm -rf "$TMP_DIR" cp -r . "$TMP_DIR" cd "$TMP_DIR" git branch -D gh-pages git checkout --orphan gh-pages rm -rf !(.git|.gitignore) cp -r "$CURR_DIR"/_build/html/* . touch .nojekyll echo "droidparts.org" > CNAME git add -A git commit -m "published" git push origin :gh-pages git push origin gh-pages rm -rf "$TMP_DIR" 

（ リンク ）

アクションのシーケンス：

1. ドキュメントを収集するスクリプトを実行します。
2. リポジトリを一時フォルダーにコピーし、そこに移動します。
3. gh-pages削除し、再度作成します。 --orphanパラメーター--orphan 、親コミットなしでブランチを--orphanます。 つまり 必要に応じて、 masterにバインドしません。 また、フォルダーをクリアします。
4. 最初のステップで生成されたファイルをコピーします。
5. .nojekyll追加して、GitHub PagesでJekyllがフォルダーに下線を引かないようにします。
6. すべてが提供されるドメインでCNAMEファイルを作成します。 当然、 DNSも構成する必要があります 。
7. 最後に、コミットし、サーバーからgh-pagesを削除し、プッシュします。

ボーナスとして、GitHub がコミットの前後の数を報告するときにバグを観察し、それを比較しようとすると...を報告します。 それともそうでしょうか？