ルール
操作内容は後に紹介するとして、まずはルールのみを列挙していきます。
リポジトリのあつかい
リポジトリは、必ず自分の個人アカウントにフォークする
フォーク元のリポジトリにはpushしてはいけない
ghq コマンドを使うと無意識にこの状態になります。
デフォルトブランチ
github-flowで master ブランチとなっている箇所は、デフォルトブランチと言い換えます。 これは、Gitの HEAD branch と同じもので、可能であるなら master ブランチであるべきです。
例外を挙げると、オープンソースのソフトウェアであるである tootsuite/mastodon をフォークし、カスタマイズしたものを公開する場合、 master ブランチではなく自分たち固有のブランチ名をデフォルトブランチとし、そのブランチでカスタマイズ開発をしたほうが良いでしょう。
デフォルトブランチは常にデプロイ可能にする
デフォルトブランチへの変更は、必ずプルリクエストで行い、絶対に直接コミットしてはいけない
開発とプルリクエスト
デフォルトブランチからブランチを切り、開発する
(開発段階で[WIP]を付けてプルリクエストし、レビューを受けながら開発する)
プルリクエストは徹底的にレビューする
プルリクエストを自動テストする仕組み(CI)を必ず導入する
プルリクエストのブランチを開発環境にデプロイし、実際に使って動作確認する
コミットとプルリクエストは次節で詳しく解説します。
プルリクエストの取り込み
プルリクエストを取り込む瞬間は、コードにバグを混入させないための最後の砦です。 どれだけ慎重になっても十分ということはありません。
最終的に、プルリクエストは必ずsquashする
徹底的に最終確認する
完璧にOKとなったら[WIP]を外す
プルリクエストをマージしたらすぐデプロイする
大規模な変更の場合
大規模な変更、例えばリニューアルの場合、リニューアル専用のブランチをつくります。 リニューアルブランチをデフォルトブランチとみなし、同じようにプルリクエストによる開発をします。
リニューアルブランチの開発が終わったら、本来のデフォルトブランチからマージ用ブランチを切り、リニューアルブランチをマージし、必要であればコンフリクトを解消し、それをプルリクエストします。 この方法はgit-flowのリリースブランチと似ているかもしれません。
なぜリニューアルブランチを直接プルリクエストせず、2ステップにするかというと、 おそらくリニューアルブランチ作業中にも本来のデフォルトブランチにも様々なコミットが入り、その場合リニューアルブランチを最新のデフォルトブランチにrebaseするのがダルいからです。
フォーク元の新バージョン対応などの場合も同様で、リニューアルブランチではなくフォーク元の特定のバージョンに変わっただけです。 デフォルトブランチから切ったマージ用ブランチに対象バージョンをマージし、大量のコンフリクトを解消し、プルリクエストします。
Last updated