Github Wikiへのコントリビューションを正しく評価するためにオープンリポジトリ管理を目指す
お詫び
Qiitaの元記事にて、区切り線を「---」で書いている場所があり、これがZennの記法に干渉して一部うまく表示できない記事がある事を認識しています。
全ての記事を精査しきれていないため、お手数ですがお見かけの際は教えていただけると大変喜びます。
結論
できました。
- Wikiをクローン
- 新しいリポジトリを生成
- ない場合は作る
- 新しいリポジトリにwikiリポジトリをpush
実験
のWikiリポジトリを
として移行したところ、過去の更新などを生きた状態でコントリビューションとして扱うことに成功しました。
これで、ドキュメンテーションもきちんとした開発貢献だと証明できそうです。
ただし、バージョン管理という観点ではいらない作業ですし、二重管理になるのでもれ抜けが発生します（後述で対策）
手引き
git clone (wiki.git)
git push --mirror 新規リポジトリ
これだけです。
発展：リアルタイム性が必要な場合
cronなりでwikiをcloneしてwikiを格納するリポジトリにpushすればいいです。
運用上正規のWikiを編集する事はあってもリポジトリを編集する事はないはずなので理論上漏れ抜けはなくせます。
応用？:プライベートリポジトリでWikiを使いたい
とりあえず方法だけ書いておきますが、運用できるとは思えません。
短期的には良いかもしれませんが、保守まで考えると現実的ではありません。
ｆWiki用のリポジトリを公開で作って記載内容をまとめ、リポジトリ自体はWikiのバックアップとしてしまう手が有効です。
もちろん、公開ができない情報を扱うのがほとんどだと思うので、非公開リポジトリにDocsなどのディレクトリを置き、キーワードを置く手もあります。
例
〜〜 情報 〜〜
# ページ情報
概要など公開できる情報。
# 接続情報
ユーザー: (USER)
パスワード: (PASSWORD)
# ページリンク
- (URL1)
- (URL2)
〜〜 情報 〜〜
秘匿したい具体的な情報。
- 接続情報
- ユーザー: (正しい情報)
- パスワード: (正しい情報)
- ページリンク
- URL1: (正しい情報)
- URL2: (正しい情報)
個人開発の場合
そもそもWiki機能がいらないと思います。
が、それも本末転倒なので運用を考えてみます。
先ほどのClosedRepository/Docs以下にREADME.mdだけを置けば、ページを降りるだけで内容が表示されます。
ただし、Wiki機能で重宝するサイドバーやフッターが使えないためページ遷移がやりにくいです。
そのため、どうしてもWiki機能を使いたい場合は、OpenWikiをただのリンク集とし、内容はClosedRepository/Docs以下に格納する手もあります。
どちらにしても、使いにくいので運用が続くとは思えません。
疑問:Github Wikiは運用足り得るか？
正直、QiitaTeamやesaなどナレッジ管理ツールを使った方がいいと思います。
ナレッジ管理ツールにも長短ありますので、どれが一概に良いか言えませんが、Github WikiやRedMine等のプロジェクト管理ツールでの運用の問題点を洗い出すと、解決ツールの策定がしやすくなると思います。[1]
そういった意味で、スモールスタートでGithub Wikiを使っておくのはアリだと思います。
注釈
-
【ナレッジベースの検討】予算の都合などから、一つのツールで全部やろうとしてしまいたくなりますが、運用コストを考えるとそれぞれの専門ツールを使って責任を分けた方が良い事があります。ツール間連携が必要な場合は別途検討が必要です。 ↩︎
Discussion