Git ワークフローの比較: 知っておくべきこと

チームのためのワークフローを評価する場合、チームの文化を考慮することがとても大切です。必要なのは、チームの効率性を高めるワークフローです。生産性を制限する重荷となるものではありません。Git ワークフローを評価する際に検討すべき点をいくつかご紹介します。

• このワークフローはチームの拡大に対応できるか。
• このワークフローは間違いやエラーを簡単に元に戻せるか。
• このワークフローは、チームにとって新たな認識を必要とする、不要な負担とならないか。

開発作業は中央リポジトリをクローンすることから始まります。それによって作成された中央リポジトリの作業コピー上で SVN の場合と同様にファイルを編集し、変更のコミットを行いますが、新たなコミットはローカルに保存され、中央リポジトリとは完全に独立しています。これにより、開発者は区切りがつくまで中央リポジトリとの同期を遅延させることができます。

中央リポジトリに対して変更を公開する場合は、ローカルの main ブランチを中央リポジトリに「プッシュ」します。これは、中央リポジトリの main ブランチに存在しないすべてのローカル コミットを追加するという点を除けば、svn commit と同等の機能です。

ここで、user には有効な SSH ユーザー名を、host にはサーバーのドメイン名か IP アドレスを、/path/to/repo.git にはリポジトリの保存場所のパスを間違いなく入力します。なお、そのリポジトリがベアリポジトリであることを表すために、習慣的に .git 拡張子を付加することに留意してください。

次に、各々の開発者が中央リポジトリ全体の作業コピー（ローカル・リポジトリ）を作成します。これには、git clone コマンドを使用します。

リポジトリをクローンすると、Git は開発者が以降その「親」リポジトリとの通信を行うものと想定してそれをポイント バックする origin という名称のショートカットを自動作成します。

既に説明したように、これらのコマンドはローカルなコミットを行うものであり、従って John は中央リポジトリで起こっていることを気にすることなくコミットを何度でも繰り返すことができます。これは、作業を単純で小規模な部分に分割する必要のある大規模フィーチャーの場合に特に有用な機能です。

このコマンドは、新たにコミットされた変更を中央リポジトリにプッシュします。中央リポジトリに変更をプッシュすると、そのプッシュによる更新と競合するコードが含まれている、それまでにプッシュされた他の開発者による更新を実行できるようになります。Git は、この競合を示すメッセージを表示します。この場合、まず git pull を実行する必要があります。この競合については、次のセクションでさらに詳しく説明します。

この場合開発者は、フィーチャーを公開する前に最新の中央リポジトリをフェッチしてその先端にローカルな変更をリベースする必要があります。この操作は、「私の変更作業は皆が変更を完了したものをベースとして行いたい」と言うに等しいものです。その結果、履歴は従来の SVN ワークフローの場合と同様に完全に直線的になります。

ローカルな変更が中央リポジトリと直接競合する場合、Git はリベースを中止して手作業で競合を解決するように促します。Git の優れている点は、コミットの作成に使用する git status と git add の 2 つのコマンドをマージ時の競合解決の際にも使用できることにあります。このことにより、新たに加わった開発者でも容易にマージを管理できます。さらに、トラブルが発生した場合はリベースを完全に中止して再試行 (またはサポートの依頼) を簡単に行うことができます。

John は、このローカルリポジトリ上で、編集、ステージ、コミットなど通常の Git でのコミット操作を駆使してフィーチャー開発を行います。

既に説明したように、これらのコマンドはローカルなコミットを行うものであり、従って John は中央リポジトリで起こっていることを気にすることなくコミットを何度でも繰り返すことができます。

一方、Mary も自分のローカルリポジトリにおいて、同じく編集、ステージ、コミットなどの操作を駆使してフィーチャー開発を始めます。John と同様に、Mary も中央リポジトリで起こっていることを気にする必要はありませんが、すべてのローカルリポジトリは非公開であるため John がローカルリポジトリで作業している内容に関しても全く気にする必要はありません。

John がフィーチャー開発を完了すると、他のチーム・メンバーがアクセスできるようにローカルなコミットを中央リポジトリに公開します。これは、次のように git push コマンドを使用して行います。

既に説明したように、origin は John が中央リポジトリをクローンしたときに Git が生成したリモート接続の名称です。main 引数は、origin の main ブランチをローカルの main ブランチに一致させるように指示しています。今の場合、中央リポジトリでは John がクローンしてから何も更新されていないため、プッシュ操作を行っても競合は発生せずに正常に完了します。

John がローカルな変更を首尾よく中央リポジトリに公開した後で Mary がフィーチャーのプッシュを試みるとどうなるでしょうか。全く同様にプッシュコマンドを使用することはできます:

しかしながら、Mary のローカルリポジトリが中央リポジトリと分岐状態にあるため、プッシュリクエストは拒否され、長文のエラーメッセージが表示されます:

この機能により、Mary が中央リポジトリに対して誤書き込みを起こすことが防止できます。Mary は、John による変更をローカルリポジトリにプルしてそれにローカルな変更を統合し、再度プッシュを試みなければなりません。

Mary は git pull コマンドを使用して中央リポジトリをプルします。このコマンドは svn update コマンドに幾分似ていて、上流の中央リポジトリ全体を Mary のローカル・リポジトリにプルしてから、それをローカルなコミットとマージしようとします。

--rebase オプションは、main ブランチを中央リポジトリの main と同期させてから、その先端に Mary のすべてのコミットを移動することを指示するもので、これを図に示すと次のようになります。

このフラグを指定しない場合もプルは可能ですが、その場合は中央リポジトリとの同期を行うたびに余計な「マージコミット」が発生します。このワークフローにおいては、三方向マージを行うのではなく常にリベースを行うことが推奨されます。

リベースでは、同期された main ブランチにローカルなコミットをひとつずつ移動します。これによって、巨大なマージ コミットを作成してすべての競合を一度に解決するのではなく、コミット別にマージ時の競合を把握することが可能になります。即ち、ひとつのコミットは焦点が明確なものとなり、プロジェクト履歴もよく整理されたものとなります。さらに、バグが入り込んだ場所の発見や、必要に応じてプロジェクトへの影響を最小限に抑えつつ変更を展開できます。

Mary と John が作業しているフィーチャーが無関係なものであった場合は、リベースの際に競合が起こる可能性は小さいものと考えられます。それでも競合が起こった場合、リベース動作は処理中のコミットで停止され、次のようなメッセージと関連情報を表示します

Git の優れている点は、誰でも自分のリポジトリで発生したマージ時の競合を解決できることにあります。この例では、Mary は直ちに git status コマンドを実行して問題の所在を確認できます。競合の発生したファイルは、マージされていないパスのセクションに表示されます。

そこで、該当のファイルに必要な編集を加えます。編集が完了したら、通常の方法でコミットしてから残りに git rebase コマンドを実行します。

これがすべてです。Git の処理は次のコミットに移り、その後競合を発生するコミットがあれば同一の処理を繰り返します。

この時点で何がどうなっているのかわからなくなっても、焦らないでください。次のコマンドを実行すれば、最初の状態に戻ることができます。

中央リポジトリとの同期が完了すると、Mary は変更を公開することができるようになります:

ここまで説明してきたように、少数の Git コマンドのみを使用して Subversion を利用した従来型の開発環境を踏襲することが可能です。これは、SVN からの移行過程にあるチームにとっては非常に有用ですが、これではGit の分散的特質を活用できません。

集中化ワークフローは、小規模なチームに適しています。上述の競合解決プロセスは、チームの規模が大きくなるとボトルネックになる場合があります。チームは集中化ワークフローに慣れ親しんでいるがコラボレーション作業の効率化が必要な場合は、フィーチャーブランチワークフローの採用を検討するべきです。このワークフローでは、各々のフィーチャーに独立した専用のブランチを割り当てることにより、変更を中央リポジトリに統合する前にそれに関する詳細な検討が可能となります。

集中化ワークフローは基本的に他の Git ワークフローの構成要素です。広く使われている Git ワークフローには、個々の開発者がプッシュおよびプルする、ある種の集中化リポジトリが含まれています。その他の一般的な Git ワークフローについて、以下に簡単に説明します。これらの拡張されたワークフローは、フィーチャー開発、ホットフィックス、最終リリースのブランチ管理において、より専門化したパターンを提供します。

フィーチャー ブランチングは、集中化ワークフローを論理的に拡大したものです。フィーチャー ブランチ ワークフローの本旨は、すべてのフィーチャー開発を main ブランチではなく専用のブランチ上で行うことにあります。このカプセル化によって、メインのコードベースに影響を与えることなく複数の開発者が別々のフィーチャー開発作業を行うことが可能になります。また、この手法によって main ブランチに不良コードが入らなくなり、継続的なインテグレーションが頻繁に行なわれる環境においては大きなメリットとなります。

Gitflow ワークフローが最初に高く評価されたのは、nvie の Vincent Driessen 氏による 2010 年のブログ投稿でした。Gitflow ワークフローは、プロジェクトのリリースに関連した利用を想定して設計された厳密なブランチ モデルを定義します。このワークフローでは、フィーチャー ブランチ ワークフローに使用されているもの以外の概念や命令は不要です。その代わり、異なるブランチに対して個別にロールを割り当て、それらが相互に作用する手順や条件を定義します。

フォーク型ワークフローは、このチュートリアルで説明した他のワークフローとは根本的に異なるものです。「中央」コードベースとして機能する単一のサーバーサイド リポジトリを使うのではなく、各々の開発者にサーバーサイド リポジトリを割り当てます。つまり、各々の開発者は、1 つの Git リポジトリではなく、非公開のローカル リポジトリと公開されたサーバーサイド リポジトリという 2 つの Git リポジトリを保有することになります。

すべてに適した Git ワークフローは存在しません。前に述べたとおり、チームの生産性が高まる Git ワークフローを作ることが大切です。ワークフローは、チームの文化だけでなくビジネス文化も補う必要があります。ブランチやタグのような Git の機能は、ビジネスのリリーススケジュールをサポートします。チームでタスク追跡プロジェクト管理ソフトウェアを使用しているなら、進行中のタスクに対応するブランチを活用できます。さらに、ワークフローを決める際に考慮すべきガイドラインを一部ご紹介しましょう。

マージを打ち消す必要のないワークフローを作ることが重要です。たとえば、main ブランチへのマージを許可する前にブランチをテストするワークフローを作成します。それでもアクシデントは発生するものですが、他のチーム メンバーの作業を妨げることなく、簡単に打ち消しを実行できるワークフローを作ることは有益です。

ワークフローは、ビジネスのソフトウェア開発リリース サイクルを補うものでなければなりません。1 日に何度もリリースする場合は、main ブランチを安定した状態に保つ必要があります。一方、リリース スケジュールの頻度がそれほど高くなければ、Git タグを使用してブランチをバージョンにタグ付けすることをお勧めします。

このドキュメントでは、Git ワークフローについて説明し、実用的な例を用いて集中化ワークフローを掘り下げました。集中化ワークフローについて詳しく説明しながら、その他の特別なワークフローについても説明しました。このドキュメントの重要なポイントは、以下のとおりです。

• すべてに適した Git ワークフローはない
• ワークフローはシンプルで、チームの生産性を高めるものである必要がある
• ビジネス要件が Git ワークフローの形成に役立つ必要がある

次の Git ワークフローについて読む前に、フィーチャーブランチワークフローの包括的な概要を確認してください。