この記事では、複数人/複数のチームで同時に作業を進めるような開発現場を想定し、GitとGitLabの具体的な運用フローを解説します。
1. 全体の開発フロー
- GitLabでdevelopブランチを作成し、基準とする(※mainブランチは安定版として扱う)
- 各メンバーが個別の作業ブランチ（例：
feature/xxxxxxxx）を作成 - 定期的に
origin/develop（作業ブランチ）を取り込みながら作業 - 作業完了後、GitLabでマージリクエスト（MR）を作成
- レビュー・承認後に
developブランチへマージ
- STEP 1リポジトリを作成（管理側が対応）
プロジェクトの基となるデータを作成
- STEP 2ローカルにリポジトリをクローン or プル
クローン：ローカルで作業するためにリポジトリを持ってくる
プル：リモートの変更をローカルに取り込む
※初期ダウンロードには時間がかかる場合があります。 - STEP 3ファイルを作成・編集する
まずはじめに、作業ブランチを切るようにしましょう！
複数のチームで対応する場合、チームマージ用のブランチを作成しましょう。
※developブランチのまま作業すると、マージの際に競合が発生する他、履歴管理が正常にできません。 - STEP 4リモートリポジトリの更新をローカルに反映させる
コンフリクト(競合)があれば、解消する
- STEP 5作業ブランチの変更内容をリモートにアップロード
チームごとの親ブランチにマージするための準備
- STEP 6MR（マージリクエスト）を作成
親ブランチにマージする際に行うレビューの準備
- STEP 7レビューとマージ
既存ブランチとの差分を出して、レビュー
すべてOKなら、マージ
※作業時は、STEP2〜7を繰り返すイメージです。
2. 個人の作業フロー
1. 作業ブランチを作成
git checkout -b feature/kinoumei2. 作業を進めてコミット
ブランチ内の変更箇所がある場合、適宜コミット（コミットルールはチーム依存）
git add .
git commit -m "コミットコメント"補足：現在の変更箇所を確認する際は下記コマンドを実行
git status3. developブランチを取り込む
他のメンバーの変更がdevelopにマージされている可能性があるため、
作業前・作業中・プッシュ前に以下を実行
作業前（プル）
git pull origin develop作業中・プッシュ前（ローカルマージ）
git fetch origin develop
git merge origin/develop4. 競合があれば修正
コンフリクトが出た場合はファイルを手動で修正し、下記コマンドでコミット
git add 修正ファイル
git commit -m "<コミットコメント>"5. リモートにプッシュ
git push origin feature/xxxxxxxx6. GitLabでマージリクエスト（MR）作成
WebGUI操作
6. マージ後、ブランチを削除
git branch -d feature/xxxxxxxx （ローカル場合）
git push origin --delete feature/xxxxxxxx （リモートの場合 ※GUI操作でも可）3. バイナリファイルが多いプロジェクトでの注意点
- バイナリは差分比較ができず、競合が起きやすい
- Git LFS（Large File Storage）の導入を検討
git lfs install
git lfs track "*.png" - バイナリファイルは担当制で更新し、同時変更を避ける
4. 開発運用のコツ（ベストプラクティス）
| 項目 | 推奨方法 |
|---|---|
| ブランチ命名 | feature/xxx, bugfix/xxx, ect… |
| developの取り込み | fetch merge or rebaseで同期 |
| マージ前 | 最新のdevelopを取り込み、競合を解決してからPush |
| レビュー | GitLabのMR機能を使ってチームで確認 |
5. まとめ
GitとGitLabを活用したチーム開発では、「developを常に最新に保ち、衝突を避ける」ことが円滑な作業のカギとなります。特にバイナリファイルを多く扱う現場では、早めの同期と明確な担当分担が重要です。
本記事がチームでのバージョン管理をスムーズに進める一助となれば幸いです。