学習で使うGitと実務のGitは違う

学習で使うGitと実務のGitは違う

プログラミング学習中のGitは、せいぜいadd、commit、pushの3コマンドで事足ります。しかし、実務のチーム開発では、ブランチ戦略、コンフリクト解消、コミット履歴の管理など、もっと多くの操作が求められます。

ここでは、実務で頻繁に使うGit操作を解説します。

ブランチ戦略の基本

Git Flowとは

多くの現場で採用されているブランチ戦略です。

GitHub Flowとは

Git Flowをシンプルにした戦略で、スタートアップや小規模チームでよく使われます。

• mainブランチが常にデプロイ可能な状態
• 新しい作業はmainからブランチを切る
• PRを作成してレビューを受ける
• マージしたら即デプロイ

ブランチの作り方と切り替え

実務でよく使うコマンドの流れ：

1. 最新のdevelopを取得する — git checkout develop && git pull
2. 新しいブランチを作成する — git checkout -b feature/user-registration
3. 作業が終わったらコミットする — git add . && git commit -m "feat: ユーザー登録機能を追加"
4. リモートにプッシュする — git push origin feature/user-registration
5. GitHubでPRを作成する

コンフリクトの解消方法

チーム開発では、同じファイルを複数人が編集することがあります。このとき発生するのがコンフリクト（競合）です。

コンフリクトが起きる原因

• 同じファイルの同じ行を、別のブランチで編集した
• 一方で削除したファイルを、もう一方で編集した

コンフリクト解消の手順

1. 最新のdevelopをマージする — git merge develop
2. コンフリクトが発生したファイルを確認する — git statusで確認
3. ファイルを開いて修正する — <<<<<<<と>>>>>>>の間の内容を確認し、正しい内容に修正する
4. 修正を確認する — 動作確認を必ず行う
5. コミットする — git add . && git commit -m "merge: developとのコンフリクトを解消"

コンフリクトを減らすコツ

• こまめにdevelopをマージする — 長期間マージしないと、大量のコンフリクトが発生する
• PRを小さく保つ — 変更範囲が小さいほど、コンフリクトの可能性が減る
• チームで編集範囲を共有する — 「今このファイルを触っています」と事前に伝える

知っておくべきGitコマンド

コミット履歴の管理

• git log --oneline — コミット履歴を一覧で確認する
• git diff — 変更内容を確認する
• git stash — 作業中の変更を一時退避する（ブランチを切り替えたいときに便利）
• git stash pop — 退避した変更を復元する

やり直し系のコマンド

• git reset --soft HEAD~1 — 直前のコミットを取り消す（変更は残る）
• git checkout -- ファイル名 — 特定のファイルの変更を取り消す
• git revert コミットID — 特定のコミットの変更を打ち消す新しいコミットを作る

注意すべきコマンド

• git push -f（force push）は原則禁止。他のメンバーの作業を上書きしてしまう可能性がある
• git reset --hardは変更が完全に消える。使う前に本当に消していいか確認する

コミットメッセージの書き方

Conventional Commitsの形式

多くの現場で採用されている規約です。

Git操作は「慣れ」がすべて

Gitの操作は、最初は怖く感じるかもしれません。特にmergeやrebaseは失敗すると大変そうに思えます。しかし、正しい手順を知り、練習を重ねれば、自然と身につきます。

ゆめさくエンジニアでは、18ヶ月の実践カリキュラムの中で、実際のチーム開発を通じてGit操作を練習します。コンフリクト解消やブランチ管理など、実務で必ず遭遇する場面を事前に経験しておくことで、現場に入ったときの不安を減らせます。

チーム開発の流れを完全解説

Git/PR/レビューの実務フローを理解する

CI/CDとは？

デプロイ自動化の仕組みを理解する

初めてのコードレビューチェックリスト

レビューで見るべき10項目を解説

ゆめさくエンジニアのカリキュラム

18ヶ月で実務力を身につける実践型カリキュラム