既に多くのチームは git への移行を済ませており、また更に多くのチームが現在その移行段階にあります。一人のデベロッパーを訓練して、採用の支援として チャンピオン を任命することは重要です。それに加え、物事をあまり複雑にしない、シンプルで扱いやすい、コードコラボレーションのプラクティスを選ぶ事が肝要です。git であれば、非常に複雑なワークフローであっても魔法のようにシンプルにできます。私は実際にそれを目の当たりにしたので、間違いありません。
ワークフローに関するマニュアルは git にインストールされてはいません。しかし、このトピックに関して多くの人が質問を抱えている事を考慮すれば、インストールされているべきかもしれません。それでもご安心下さい。我々は役に立つ資料を作るべく、現在奮闘中です。
ワークフローに関する最近のウェビナーおよびガイド
キレイな写真や、文字を読むのが好きな方には、我々の git チュートリアルサイトの最も人気のあるセクションの一つである ワークフロー セクションがお勧めです。
ただし、これらのセクションを探索する前に、もうしばらくお付き合い下さい。非常にクールな話をお伝えします。
継続的デリバリー の簡単なワークフローに関する、簡潔かつ完全な説明をしたいと思います。前提条件として、あなたとあなたのチームは少なくとも git に多少は慣れ親しんでいる事、そして二つの形式 (インタラクティブとそうではないもの) の rebase コマンドに関する十分な知識を有している事が求められます。
継続的デリバリーにおけるブランチ ワークフローの基本中の基本
私が説明したい簡単なワークフローには、二つのガイド的な原則が存在します。
- master は、プロダクション（本番稼働）でデプロイ可能なもののみを扱う
- rebase をフィーチャー開発中に行い、終了したら明示的に mergeする (非ファストフォワード)
rebase を使用して変更セットをプルすると、作業中のブランチの履歴を書き換え、変更内容を一番上に保ちます。
このワークフローにおいて求めている rebase は、二つ目の図にあります。
これらのガイド的な原則を学んだところで、七つのステップを解説していきましょう。
1. 初めに、masterから最新の変更内容をプルする
これは、一般的な git コマンドを利用する事で可能です。
2
3
git fetch origin
git merge master
私は fetch/merge を利用してより明示的でありたいのですが、この二つのコマンドは git pull origin masterと同等のものです。
2. フィーチャー分離あるいはバグ修正作業のためにブランチを作成する
次に、機能あるいはバグ修正のためにブランチを作成します。
ここでお見せしているブランチ名構造は単に我々が使用しているものであり、皆さんは慣れ親しんだやり方を選んで頂いて結構です。
3. フィーチャーに関する作業を開始する
必要なだけの時間を割いて、機能の作業を行って下さい。必ず、コミットは有意義なものにして、別々の変更内容のクラスタリングを行わないで下さい。
4. フィーチャーブランチを、マスターにおける最新の変更内容でアップデートし続けるには、rebaseを利用する
開発アップデートの間は、定期的にmasterにおける最新の変更内容で機能ブランチをアップデートします。これは、以下の方法で行います。
2
git rebase origin/master
同じ共有のリモート機能ブランチにおいて、他の人たちも作業しているという、どちらかといえば珍しいケースにおいては、その変更内容もまた rebase します。
この時点で、リベースから出現する一切のコンフリクトを解決します。
rebase 中にコンフリクトを解決する事で、機能開発の最後には常にクリーンなマージを得られます。また、これによって機能ブランチの履歴をクリーンに保つ事で、偽りのノイズに気をもまれる必要がありません。
5. フィードバックを受ける準備が整ったら遠隔的にブランチをプッシュして、プルリクエストを作成する
作業内容を共有して、フィードバックを受ける準備が整った場合、以下の方法でブランチを遠隔的にプッシュします
2
3
(if the branch is already set as 'upstream' and your remote is called 'origin', 'git push' is enough)
こうして、お好みの git サーバ (例えば Stash または Bitbucket)上でプルリクエストを作成できます。 最初のプッシュ後は、リモートブランチに何度もアップデートをプッシュし続けられます。これは、フィードバックに対する反応、あるいは機能開発がまだ終了していない場合に発生する可能性があります。
6. プルリクエストの承認を得られた後、最後の rebase クリーンアップを行う
レビュー後は、機能ブランチの履歴の最終クリーンアップと整理を行い、関連情報を提供していない偽のコミットを取り除くといいでしょう。あなたのチームが経験豊富で対応できるのであれば、開発中に rebase する事も可能です。しかし、私はこれを全くお勧めしません。
(この時点で、発行したブランチの履歴を書き換えており、また他の誰もがこれに対してコミットしたり、これを使用しないのであれば、–force フラグを利用して、変更内容をプッシュする必要があるかもしれません)
7. 開発の完了後は、明示的なマージを記録する
機能ブランチの開発が終了し、レビュワーがあなたの作業内容をレビューした後は、–no-ffフラグを使用してmerge します。これによって、作業内容が保存され、必要な場合には簡単に全機能を元に戻す事もできます。以下は、そのコマンドです。
2
3
4
git pull origin master
git merge --no-ff PRJ-123-awesome-feature
上記アドバイスに従い、rebase を使用して機能ブランチを最新状態に保っていたのであれば、実際のマージコミットには一切の変更が含まれません。これは素晴らしい事です！マージコミットは、機能ブランチに関するコンテキストを保管する、単なるマーカーとなります。 詳しくは、私の最新記事であるマージの実行 vs リベースワークフローにおける良い点と悪い点を参照して下さい。
トグルする際に便利な .gitconfig オプション
git に指示を出す事で、あらゆるpull がmergeの代わりにrebase を使用して、その間を保存するようにできます。
2
git config --global pull.rebase preserve #(this is a very recent and useful addition that appeared in git 1.8.5)
誰しもが主要コマンドのデフォルト行動を変更したい訳では無いので、それがもたらす影響をよく把握した上で上記を取り入れるべきでしょう。preserve merge の詳細に関しては、Stack Overflow を参照して下さい。
結論
これで、ワークフロー、ブランチモデル、そしてコードコラボレーションでできることについて十分な資料となった事でしょう。git についてもっとクールなことを知りたい場合は、@durdn で私を、そして @AtlDevtools チームをフォローしてみてください。 謝辞: 本投稿内容は、簡潔かつ優れた gistから一部インスピレーションを受けて執筆しました。
*本ブログは Atlassian Blogs の翻訳です。本文中の日時などは投稿当時のものですのでご了承ください。
*原文 : 2014 年 2 月 9 日 "Simple Git workflow is simple"