Merge Requestとは？
チーム内でソースコードのレビューをすることです。同様の機能にGitHubのプルリクエストが有名ですが、Pull(取り込んでもらう）ことに着目した名前なのに対して、マージリクエストはマージすることに着目した名前になっています。
Merge Requestの種類
以下の二つのフローがあります。
- 保護ブランチワークフロー
- フォークワークフロー
保護ブランチワークフロー
開発メンバー同士が全員同じGitLabプロジェクトで作業を行います。
Masterブランチを保護対象（Protected)として扱っていレビュー権限を持った管理者にだけ更新作業の制限をかけます。それぞれの開発者はDeveloperアクセス権限だけ割り振られてます。各開発者はローカルリポジトリに機能ブランチを作成して、Masterブランチに対してpushをする形で作業を進めます。
プロジェクトごとにリモートリポジトリを一つだけ管理すれば良いので開発手順やリポジトリ構造の複雑化を防ぐことが可能です。社内のチーム開発等の開発者が特定できる環境でよく利用される開発方式です。
手順
|
1 2 3 4 5 6 7 |
git clone レポジトリのURL(https://xxxx.yyy.git) git checkout -b 機能ブランチ名 git branch -a 編集 git add . git commit -m "コミットメッセージ" git push origin master(マスターブランチの名前) |
フォークワークフロー
Masterブランチへのマージは限られたメンバーが行い、開発メンバーはフォークして開発を行います。フォークは別リポジトリに書き込む権限がない場合でも作業依頼ができる機能なので元のリポジトリに影響を与えることなく開発を進められます。
開発者側でフォークしたリポジトリを最新に保つ必要があり、複数リポジトリを管理するという視点ではより高度なGitスキルが求められることになります。管理が複雑になるので通常の社内開発では採用されません。OSSの開発等の不特定多数の開発者が同時に開発する方式等で安易に元のリポジトリに影響を与えたくない開発等の場合に使われます。
機能ブランチの開発規模
一つの機能ブランチは極力小さいことが望ましいです。一つの修正に対する修正量が増えてしまうとレビューでの見落としにつながってしまう可能性が高くなります。
テストの自動化
テストやlinterの自動化にReview Appという機能があります。
この記事へのコメントはありません。