【初心者の方も安心】Gitで避けたい主なトラブル10選
山崎講師こんにちは。ゆうせいです。
Gitはソースコードのバージョン管理ができる便利な仕組みですが、誤った使い方をすると大きな問題が生じる場合があります。新人エンジニアの方がつまずきやすいポイントや、やりがちなミスをまとめました。
丁寧な言葉遣いを心がけつつ、ご自身やチームの作業を安全かつスムーズに進められるように一緒に学んでみましょう！
なぜ気をつけたい行為を知るとよいのか
Gitは共同開発を効率的に進められる反面、操作や運用ルールを誤ると「ほかの人の作業を上書きしてしまった」「自分の進めていた作業が消えてしまった」という事態につながりかねません。
いわば、チーム共有のノートに書き込みをするときと似た部分があるため、「いつ誰が何を書いたのか」を意識しながら運用することが大切です。
下記のポイントを把握して、安心感のある開発ライフを目指してみてくださいね。
目次
- こまめな同期をしない
- コミットを細切れにしすぎる
- 常にメインブランチで直接作業する
- マージやリベースの仕組みを理解しないまま運用
- 競合を避けて解消せず放置する
- 強制プッシュ（force push）を多用する
git reset --hardを安易に使う.gitignoreを設定せずに大容量ファイルや機密情報をコミット- コミットメッセージを雑に書く
- コメントアウトや仮コードをそのまま残す
1. こまめな同期をしない
解説
ローカルリポジトリとリモートリポジトリを同期しないまま作業を続けると、一度に大きな変更差分が発生して競合（コンフリクト）が多発しがちです。
例え
友人と共同でノートを使っているのに、相手の書き込みを確認しないまま自分だけが大幅に追記をしてしまうような状況をイメージできます。
対策
- 作業開始前やコミット後など、節目で
git pullとgit pushを定期的に実行 - 小まめに同期することで、競合箇所を最小限に抑えられます
2. コミットを細切れにしすぎる
解説
1行修正するたびにコミットする、ビルド後のファイルをコミットするなど、履歴が増えすぎると過去の変更を振り返りにくくなります。
例え
「このページを書いた」「行を増やした」「さらに一句追加」と細切れにノートへ書いていると、どこを見れば内容がまとまっているのか分かりづらくなる状態です。
対策
- 機能単位でコミット：ひとかたまりの処理が終わったところでコミット。最初は実行して動いたらコミットでも可。
- 不要ファイルは
.gitignoreで除外：ビルド成果物やエディタの設定ファイルなどは履歴から外します
3. 常にメインブランチで直接作業する
解説
メインブランチ（masterやmain）で直接作業を続けると、バグ修正や新機能開発の区切りがつかなくなり、問題があってもどの段階で導入されたか分かりにくくなります。
図1：ブランチ構成のイメージ
┌─ featureXブランチ
(main) ─┼─ featureYブランチ
└─ bugfixブランチ
それぞれ並行して開発・修正を行い、完成後にメインブランチへマージすると履歴が整理しやすいです。
対策
- 機能ごと、バグ修正ごとにブランチを切る
- 完了後にメインブランチへ統合し、履歴を整理
4. マージやリベースの仕組みを理解しないまま運用
解説
git mergeとgit rebaseは共にブランチを統合する方法ですが、ヒストリー（履歴）の扱い方が異なります。やり方を誤ると、履歴が複雑になったり他メンバーの変更と衝突しやすくなります。
数式で表すと
- リベース
- Rebase = Rewrite History + Replay Commits
- リベース = 履歴の付け替え + 再適用
例え
出来事を時系列で並べたいのに、日付を強引に書き換えてしまうような状況です。誰がいつ何をしたか分からなくなってしまうことがあります。
対策
- 初心者のうちは
merge中心で問題なし - リベースを行う際は必ずバックアップ用に別ブランチを用意して、万が一に備える
5. 競合を避けて解消せず放置する
解説
競合（コンフリクト）は、複数人が同じファイルの同じ箇所を修正したときなどに起こります。慣れないうちは怖く見えますが、避け続けると後でより大きな変更差分が積み重なり、複雑になる可能性があります。
例え
クラスメイトと同じ宿題部分に別の答えを書き込んでしまった状態です。どちらを採用するか、あるいは折衷案にするかを決めるまでは次に進めません。
対策
- 競合解消ツール（VSCodeやその他エディタ）で差分を確認
- こまめなプルとプッシュで競合発生を最小限に
6. 強制プッシュ（force push）を多用する
解説
git push --forceを使うと、リモート上の履歴を無理やり上書きします。ほかのメンバーがプッシュした変更を意図せず消し去ってしまう危険があります。
数式で表すと
- 強制プッシュ = 強制上書き + プッシュ
- Force Push = Overwrite + Push
例え
クラスの共同ノートを「自分のメモだけが正しい！」という気持ちで書き換えてしまう感じです。ほかの人の修正が反映されなくなってしまいます。
対策
- どうしても履歴を修正したい場合はチーム全体で合意を取る
--force-with-leaseオプションを使うと、ほかの人が更新していないか確認しながら上書きが可能
7. git reset --hardを安易に使う
解説
git reset --hardはローカルの履歴や作業内容を強制的に巻き戻す操作です。確認せずに使うと、必要な変更まで消してしまいかねません。
例え
ノートをまとめている途中で「一度消してしまおう」と消しゴムを使ったら、大事な内容まで消してしまったような状態です。
対策
git revertで特定のコミットを取り消す：履歴を丸ごと壊すリスクを低減- 慣れていないうちは別ブランチで検証してから実行し、本当に必要かどうか確認
8. .gitignoreを設定せずに大容量ファイルや機密情報をコミット
解説
ビルド成果物や秘密鍵などを誤ってリポジトリに含めると、容量が肥大化したりセキュリティリスクが発生します。クローンやプルに時間がかかり、チーム全体の生産性が下がる場合もあります。
例え
共有フォルダにテスト回答やパスワードが書かれたメモをそのまま放置するようなイメージです。
対策
.gitignoreを用いて不要ファイルを管理- 機密情報は別の安全な方法（環境変数や暗号化ストレージなど）で保管
9. コミットメッセージを雑に書く
解説
「修正」「update」など、内容が分からないままのコミットメッセージが増えると、履歴を追跡するときに苦労します。後から原因を調べたい場合や、他メンバーが変更内容を把握したいときに大変です。
例え
授業のノートに「またちょっと追加した」「少し変更」とだけ書いてあり、どのタイミングでどう変わったのか不明瞭になる状況です。
対策
- プレフィックスを活用：
feat: 〇〇機能追加,fix: 〇〇バグ修正など、ある程度形式化するとチームにも伝わりやすいです。 - 理由を含める：何を、なぜ修正したのかを簡潔にまとめると読み返しやすくなります。
10. コメントアウトや仮コードをそのまま残す
解説
開発途中の実験コードや大量のコメントアウトをコミットに含めると、レビューやデバッグの際に混乱を招く恐れがあります。
例え
下書きをそのまま本番原稿に載せるような感覚です。周囲は何が最終的な仕上げか見分けにくくなります。
対策
- ブランチの段階で不要部分を整理してからコミット
- 必要なコメントには「なぜコメントアウトしているのか」を明記
NG行為一覧表
| 項目 | やりがちな行為 | 対策 |
|---|---|---|
| 1 | こまめな同期をしない | 小まめにgit pull・git push |
| 2 | コミットを細切れにしすぎる | ひとかたまりの処理が終わったところでコミット。最初は実行して動いたらコミットでも可。 |
| 3 | 常にメインブランチで直接作業 | 機能・バグ修正ごとにブランチを分ける |
| 4 | マージやリベースの理解不足 | まずはmergeで慣れ、リベースはバックアップを取って慎重に行う |
| 5 | 競合を避けて解消しない | 競合解消ツールを使い、少しずつでも練習 |
| 6 | 強制プッシュを多用 | 必要性をよく検討し、--force-with-leaseを推奨 |
| 7 | git reset --hardを安易に使う | git revertで取り消すなど、巻き戻しは慎重に |
| 8 | .gitignore未設定のまま大容量ファイルや機密情報をコミット | .gitignoreで除外・秘密情報は環境変数や暗号化ストレージで管理 |
| 9 | コミットメッセージを雑に書く | プレフィックスを付与し、変更理由も簡潔に記す |
| 10 | コメントアウトや仮コードをそのまま残す | ブランチ内で整理し、必要なコメントには理由を記載 |
今後の学習の指針
- 主要コマンドやブランチ戦略を復習
git pull,git push,git mergeなどの基本に改めて目を通し、ブランチ戦略（GitフローやGitHubフローなど）に触れてみると理解が深まります。 - 競合解消の練習
意図的にファイルを競合させ、解消ツールを使いこなす練習を行うと実務ですぐに対応できるようになります。 - コミットメッセージのテンプレート化
チームで作業する際にはメッセージのフォーマットを揃えると履歴が追いやすくなり、コミュニケーションも円滑になります。 - 細かいブランチ運用で安心感を
ちょっとした修正でも気軽にブランチを切り、問題がなければメインブランチへ取り込む運用を心がけるとリスクが減ります。
大きなトラブルは、たいてい小さな積み重ねがきっかけになります。上記のポイントを意識して、気持ちよく開発を進められるようご活躍をお祈りしております！
セイ・コンサルティング・グループの新人エンジニア研修のメニューへのリンク
投稿者プロフィール
- 代表取締役
-
セイ・コンサルティング・グループ株式会社代表取締役。
岐阜県出身。
2000年創業、2004年会社設立。
IT企業向け人材育成研修歴業界歴20年以上。
すべての無駄を省いた費用対効果の高い「筋肉質」な研修を提供します！
この記事に間違い等ありましたらぜひお知らせください。
最新の投稿
新入社員2025年2月23日【新人エンジニア必読】「入りを量りて出を制す」の考え方を仕事に活かす- 新人エンジニア研修講師2025年2月23日丁寧なのにイラッとする言葉
- 新入社員2025年2月23日【初心者の方も安心】Gitで避けたい主なトラブル10選
- 新入社員2025年2月23日【新人エンジニア向け】損失回避バイアスを知って開発リスクを減らそう
