チーム開発を行う上で、Gitは欠かせないツールです。その中でも「ブランチ」と「マージ」はプロジェクトの進行に大きな役割を果たします。
本カリキュラムでは、ブランチの作成と活用方法、マージの基本、Pull Request（PR）の活用方法、そして避けて通れないコンフリクトの解決方法まで、Gitの基本操作を実践的に学んでいきます。
1. ブランチの作成と利用
ブランチとは？
Gitの「ブランチ」は、プロジェクト内で別々の作業を同時に行うための仮想的な作業環境です。
プロジェクトを複数人で開発する場合、各メンバーが同じファイルに異なる変更を加える可能性があります。
そのような場合に、ブランチを作成することで、メインのコード（通常はmainまたはmasterブランチと呼ばれます）に影響を与えることなく、独立して作業を進められます。
ブランチの作成手順
1. 既存のリポジトリでブランチを作成する:
ブランチの作成は非常に簡単で、次のコマンドを使用します。
git branch <ブランチ名>例: feature/login という名前のブランチを作成したい場合は以下のようにします。
git branch feature/login2. ブランチの切り替え:
ブランチを作成した後は、作業を行うためにそのブランチに「チェックアウト」する必要があります。
git checkout <ブランチ名>例: feature/login ブランチに切り替える場合。
git checkout feature/loginGitのバージョンが2.23以降であれば、git switchコマンドも利用できます。
git switch feature/login3. ブランチ作成と同時に切り替える:
ブランチを作成してすぐにそのブランチに移動したい場合、次のように1行で実行できます。
git checkout -b <ブランチ名>例: feature/loginブランチを作成してすぐに切り替える場合。
git checkout -b feature/loginブランチの活用方法
ブランチは、さまざまな目的で作成されます。以下は、ブランチを活用する際の一般的なシナリオです。
1. 新しい機能の開発（Featureブランチ）:
新しい機能を追加するときには、通常feature/という名前でブランチを作成し、その中で開発を行います。
例えば、ログイン機能を開発する場合は、feature/loginブランチで作業を行い、テストが完了したらメインブランチに統合します。
2. バグ修正（Bugfixブランチ）:
既存のコードにバグが発生した場合、そのバグ修正用のブランチを作成します。
命名規則として、bugfix/ を使うことが一般的です。例えば、ログイン画面のバグを修正するためにbugfix/login-screen というブランチを作成します。
3. ホットフィックス（Hotfixブランチ）:
リリース後に重要なバグが発見された場合、hotfix/ というブランチを作成し、緊急で修正を行うことがあります。
リリース後のブランチとは異なるため、迅速な対応が可能です。
ブランチの確認と管理
1. 現在のブランチを確認する:
作業中のブランチを確認するには、以下のコマンドを使用します。
git branch現在アクティブなブランチにはアスタリスクが表示されます。
2. リモートブランチの確認:
リモートリポジトリに存在するブランチを確認するには、以下のコマンドを使用します。
git branch -r3. 全ブランチ（ローカル＆リモート）の確認:
全てのブランチ（ローカルブランチとリモートブランチ）を確認するには、次のコマンドを使用します。
git branch -aブランチを活用するメリット
- 並行作業が可能:チームメンバーが異なるブランチで同時に作業できるため、開発効率が向上します。
- リスク軽減:メインのコードベースに影響を与えずに新しい機能やバグ修正を行うことができます。途中で問題が発生しても、メインブランチは安定したままです。
- レビューとマージが容易:作業が完了したブランチは、Pull Requestを介してレビューを受けることができ、他のメンバーの確認後にメインブランチにマージできます。
2. マージの基本
マージとは？
「マージ（merge）」は、あるブランチで行った変更を他のブランチ（通常はメインブランチ）に統合するプロセスです。
たとえば、新しい機能を開発するためにfeatureブランチを作成し、そのブランチでの作業が完了したら、変更をメインブランチにマージします。
マージにより、複数の作業を1つにまとめ、コードベースの一貫性を保つことができます。
マージの仕組み
Gitでは、マージを行う際に2つの主な方法があります。
1. Fast-forwardマージ:
Fast-forwardマージは、メインブランチがマージ対象のブランチと異なる変更が一切ない場合に発生します。
この場合、単にブランチのポインタを先に進めるだけでマージが行われます。
ブランチ履歴が非常にシンプルで分かりやすくなるのが特徴です。
例:
git checkout main
git merge feature/loginこのコマンドにより、feature/loginブランチでの変更がmainブランチにFast-forwardマージされます。
2. 3-wayマージ:
Fast-forwardマージができない場合、Gitは3-wayマージを行います。
これは、2つのブランチ間で異なる変更があるときに、その共通の祖先（ベース）からの差分を計算し、変更を統合する方法です。
3-wayマージにより、ブランチ履歴にマージコミットが追加されます。このマージコミットは、両方の変更がどのように統合されたかを記録しています。
例:
git checkout main
git merge feature/loginマージの手順
1. 作業ブランチを最新にする:
マージを行う前に、ブランチが最新であることを確認します。
リモートリポジトリの最新情報を取得し、ブランチに反映させるには次のコマンドを使用します。
git fetch
git pull origin <ブランチ名>これにより、他のチームメンバーが行った変更を事前に確認し、自分の作業ブランチと最新の状態にしてからマージを行えます。
2. メインブランチに切り替える:
マージを行う際は、最終的に変更を統合したいブランチに切り替えます。
通常、メインブランチ（mainまたはmaster）に変更をマージします。
git checkout main3. マージを実行する:
マージしたいブランチ（例: feature/login）の変更をメインブランチに統合します。
git merge feature/loginこのコマンドを実行することで、feature/loginブランチの変更がmainブランチに統合されます。もしFast-forwardマージが可能なら、そのまま進行し、異なる変更があれば3-wayマージが行われます。
マージのベストプラクティス
1. 小まめにマージを行う:
大規模な変更を一度にマージするとコンフリクトが発生しやすくなるため、小まめにマージを行い、コンフリクトの発生を最小限に抑えましょう。
2. Pull Requestを活用する:
直接メインブランチにマージするのではなく、Pull Requestを通してチームメンバーとコードレビューを行うことで、問題を事前に発見しやすくなります。
3. 頻繁にリモートの変更を取り込む:
作業中のブランチに対して、頻繁にgit fetchやgit pullを行い、リモートリポジトリの最新情報を取り込むことで、メインブランチとの差分を常に確認し、コンフリクトを防ぐことができます。
3. Pull Requestの使い方とコードレビュー
Pull Request（PR）とは？
Pull Request（PR）は、GitHubやBitbucket、GitLabなどのバージョン管理システムで使用される機能で、ブランチでの作業が完了した際に、他のブランチ（通常はメインブランチ）に変更を統合する前にレビューを依頼するプロセスです。
PRは、コードレビューを促進し、バグやパフォーマンス問題の発見を助けるため、より品質の高いコードを維持するのに役立ちます。
PRの作成方法
1. 変更をコミットする:
PRを作成するには、まずローカルの作業ブランチで行った変更をコミットし、リモートリポジトリにプッシュする必要があります。
git add .
git commit -m "新しい機能の追加"
git push origin <ブランチ名>2. PRを作成する:
リモートリポジトリにプッシュした後、GitHubやGitLabのUIからPRを作成します。
• GitHubの場合:
- 自分のリポジトリにアクセスし、対象ブランチを選択します。
- 画面上部に表示される「Compare & pull request」ボタンをクリックします。
- PRのタイトルと説明を入力します。説明には、どのような変更を行ったのか、その目的や影響範囲などを詳しく記載します。
- 「Create Pull Request」をクリックしてPRを作成します。
PR作成時のポイント
1. 明確なタイトルと説明:
PRのタイトルと説明は、他のチームメンバーが何をレビューすべきかを理解するための重要な情報です。
次の内容を含めると良いでしょう。
- 何を変更したか（機能追加、バグ修正など）。
- なぜその変更が必要だったか。
- 変更が他の部分にどのような影響を与えるか。
2. 小規模な変更を心掛ける:
大規模な変更を一度にPRするのは避け、小さな単位でPRを作成することで、レビューが容易になり、変更の影響範囲を把握しやすくなります。
3. 自分の変更をテストする:
PRを作成する前に、必ず自分の変更をテストし、エラーやバグが発生していないことを確認しましょう。
自動テストを実装している場合、テストが通っているかを確認するのも重要です。
効果的なコードレビューのポイント
コードレビューは、他のチームメンバーのコードを確認し、バグや問題を見つけたり、改善点を指摘したりするためのプロセスです。
効果的なコードレビューを行うためのポイントは以下の通りです。
1. コードの理解と背景の確認:
コードレビューを始める前に、PRの説明や関連するチケット（タスク管理システムでの課題）を確認し、どのような背景で変更が行われたのかを理解しましょう。
2. コードの可読性を重視する:
コードが他の開発者にとって読みやすく、理解しやすいかどうかを確認します。
コメントが適切に追加されているか、命名規則が統一されているか、関数やクラスが適切に分割されているかがポイントです。
3. バグやパフォーマンス問題を確認する:
コードにバグが潜んでいないか、またはパフォーマンスに影響を与える可能性がないかを確認します。
必要に応じて、テストケースを見直し、実際に動作するかどうかをテストすることも重要です。
4. 改善提案をポジティブに行う:
問題を指摘する際には、単に「間違っている」と言うのではなく、改善のための具体的な提案を行い、建設的なフィードバックを心掛けましょう。
例: 「ここで使用しているループは、パフォーマンスの観点から改善できるかもしれません。map()関数を使うと、より簡潔に書けます。」
5. 一貫性を保つ:
コードがプロジェクト全体で一貫性を保っているか確認します。
特に、コードスタイル、フォーマット、命名規則が一致していることが重要です。
Lintツールなどを使って、自動的にスタイルチェックを行うことも有効です。
PRのマージ
コードレビューが完了し、レビューアーが承認を与えたら、PRをメインブランチにマージすることができます。
PRが承認された後の手順は次の通りです。
1. CI/CDテストの確認:
PRをマージする前に、テストが全て通過しているかを確認します。
CI（継続的インテグレーション）を導入している場合、自動でテストが実行され、その結果を確認することができます。
2. マージ方法の選択:
GitHubなどでは、PRをマージする際に、いくつかのマージ方法を選択できます。
- 通常のマージ: PRの変更をそのままマージコミットとして統合します。
- Squash and merge: 複数のコミットを1つのコミットにまとめてからマージします。
- Rebase and merge: コミット履歴を再構成し、クリーンな履歴を維持しつつマージします。
3. マージ後のブランチ削除:
PRをマージした後は、不要になったブランチを削除してプロジェクトを整理します。
GitHubでは、PRマージ後に自動的にブランチを削除するオプションもあります。
git branch -d <ブランチ名>4. コンフリクトの解決方法
コンフリクトとは？
コンフリクト（衝突）は、複数のブランチで同じファイルの同じ部分が異なる方法で変更された場合に発生します。
Gitは自動的にこれらの変更を統合できないため、開発者が手動で解決する必要があります。
コンフリクトはチーム開発において避けられないものですが、解決手順を理解していれば、特に恐れる必要はありません。
コンフリクトの原因
コンフリクトが発生する主な原因は次の通りです:
- 同じファイルの同じ箇所が異なるブランチで変更されている場合:
例えば、mainブランチでファイルの1行目を変更し、同じファイルの1行目をfeatureブランチでも変更していた場合、これがコンフリクトの原因となります。 - 複数のブランチで同時にファイルが追加、削除された場合:
例えば、あるブランチでファイルを削除した一方で、別のブランチでそのファイルを変更していた場合、コンフリクトが発生します。
コンフリクトの解決手順
1. マージを試みる:
まずは、通常通りマージを実行します。
コンフリクトが発生した場合、Gitは自動的にそれを検出し、警告メッセージを表示します。
git merge <ブランチ名>コンフリクトが発生すると、次のようなメッセージが表示されます。
Auto-merging <ファイル名>
CONFLICT (content): Merge conflict in <ファイル名>2. コンフリクトの確認:
コンフリクトが発生したファイルは、Gitがマークを付けているため、エディタでファイルを開き、手動で解決します。
コンフリクト部分は次のように表示されます。
<<<<<<< HEAD
こちらのブランチの変更内容
=======
マージしようとしているブランチの変更内容
>>>>>>> <ブランチ名>このマーカーが表示されている箇所が、どの部分がどのブランチから来た変更なのかを示しています。<<<<<<< HEADの後が自分のブランチでの変更、=======の後がマージ対象ブランチの変更です。
3. コンフリクトの解決:
次に、どの変更を採用するか、あるいは変更を統合するかを判断し、ファイルを手動で修正します。
コンフリクトが解決したら、マーカー（<<<<<<<, =======, >>>>>>>）を削除して、ファイルを保存します。
例えば、次のように修正します。
コンフリクト前:
<<<<<<< HEAD
const message = "Hello from my branch!";
=======
const message = "Hello from feature branch!";
>>>>>>> feature/loginコンフリクト解決後:
const message = "Hello from both branches!";4. コンフリクト解決後の処理:
コンフリクトが解決したら、その変更をステージングしてコミットします。
git add <コンフリクト解決済みファイル>
git commitこれにより、コンフリクト解決後のマージが完了し、コードベースに統合されます。
コンフリクト解決のベストプラクティス
1. 頻繁にマージを行う:
長期間ブランチを分岐させたままにしておくと、コンフリクトが発生する可能性が高まります。
できるだけこまめにマージを行い、コンフリクトを未然に防ぐことが重要です。
2. ローカルでのコンフリクト解決を優先する:
リモートブランチにプッシュする前に、ローカルでコンフリクトを解決してからリモートに統合することが望ましいです。
そうすることで、他のチームメンバーに影響を与える前に解決できます。
3. チーム内でのコミュニケーション:
コンフリクトはチームメンバー間のコミュニケーション不足から発生することもあります。
特に同じファイルを扱う場合、事前に作業内容や変更点を共有することで、コンフリクトの発生を抑えることができます。
4. ツールを活用する:
多くのIDEやGitツールは、コンフリクト解決のための支援機能を備えています。
VSCodeやGitKrakenなどのツールは、コンフリクト部分を視覚的に表示し、解決を手助けします。
まとめ
Gitブランチとマージ、Pull Requestの基本を理解することは、チーム開発を円滑に進めるための基礎です。
本カリキュラムを通じて、Gitの操作スキルを高め、コンフリクトにも柔軟に対応できる力を身につけましょう。
