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 がコミット前後の数を報告するときにバグを観察し、それを比較しようとすると...を報告します。 それともそうでしょうか?



All Articles