エンジニア初心者が現場でスムーズに仕事をするためには、バージョン管理システムとして広く利用されているGitの基本的な使い方をしっかりと押さえておく必要があります。本稿では、Gitの概要やよく使われるコマンド、実務での注意点に加え、GUIツールとして有名なSourceTreeとの使い分けにも触れながら、最低限知っておきたい事項を詳しく説明します。できるだけ重複内容を避けつつ、初学者に向けて噛み砕いて解説していきます。

1. Gitの概要

Gitは、ソフトウェア開発でソースコードやドキュメントなどを効率的に管理するための分散型バージョン管理システムです。分散型というのは、各開発者のローカル環境にも完全なリポジトリ（履歴情報を含む）が存在し、インターネット上あるいは社内ネットワーク上などのサーバー側にあるリポジトリ（リモートリポジトリ）と同期しながら開発を進められる仕組みを指します。SVNなどの集中型バージョン管理システムと異なり、ローカル環境だけで過去の履歴を全て確認できるのがGitの特徴の一つです。

1.1 なぜGitが必要なのか？

共同開発の効率化：複数人で同じソースコードを編集する場合、誰がどのタイミングで何を変更したかを明確に追跡できます。
安全な履歴管理：過去の変更履歴を簡単に遡り、特定のバージョンに戻すなどの操作が可能です。
ブランチの活用：複数の開発作業を並行して進めても、メインブランチに影響を与えずに変更を行えるため、リスクを最小限にできます。
柔軟な運用：チームの方針やプロジェクトの規模に合わせてBranch戦略（Git-FlowやGitHub Flowなど）をカスタマイズできます。

Gitは、オープンソースプロジェクトから大規模企業のソフトウェア開発まで幅広く利用されており、一度仕組みを理解してしまえば多くの現場で共通の知識として活かせるため、学習効果の高いツールといえます。

2. リポジトリの構造と概念

Gitでは作業を行う単位となる保管庫を**リポジトリ（Repository）**と呼びます。リポジトリには大きく分けて以下の2種類があります。

ローカルリポジトリ：開発者の手元（PCやノートパソコンなど）にあるリポジトリ
リモートリポジトリ：GitHubやGitLab、Bitbucketなどのホスティングサービス（クラウド上や社内サーバーなど）で管理されるリポジトリ

基本的な開発フローとしては、リモートリポジトリの内容をローカルにclone（コピー）してきて、そこでコードを編集・コミットし、定期的にリモート側へプッシュするという形になります。ローカルがオフラインでもコミットや過去履歴を参照できるのがGitならではの強みです。

2.1 作業ディレクトリとステージエリア

Gitでは、ファイルの変更が次のような段階を踏みます。

作業ツリー（ワーキングツリー/作業ディレクトリ）：実際にファイルを編集している場所
ステージエリア（インデックス）：次のコミットに含めたい変更を一時的に登録する場所
ローカルリポジトリ：コミットされた変更の履歴が蓄積されていく場所

この段階構造を理解することで、Gitの基本操作がスムーズになります。たとえば、git add .をするとステージエリアに変更が登録され、git commit -m "～"をしたタイミングでローカルリポジトリに変更内容が保存（コミット）されます。

3. Gitの基本コマンド

ここでは、実務で特に頻繁に使われるコマンドを中心に解説します。それぞれのコマンドが何を行うのかをしっかり把握することが大切です。

上記のように、Gitでは必要な手順を踏んでリモートリポジトリへ変更を反映します。

3.1 git clone

リモートリポジトリをローカルにコピーして、開発をスタートさせる
例：git clone https://github.com/ユーザー名/リポジトリ名.git

3.2 git branch / git checkout / git switch

git branch [ブランチ名]：新しいブランチの作成
git checkout [ブランチ名]：指定したブランチに移動
git checkout -b [ブランチ名]：ブランチ作成 + そのブランチに移動
git switch [ブランチ名]：Gitの新しいバージョンで推奨されるブランチ切り替えコマンド

ブランチを切ることで、本筋（メインブランチ）のコードを壊さずに新機能開発やバグ修正を並行して進められるようになります。

3.3 git add / git commit

git add [ファイル名やディレクトリ]：ファイルの変更をステージエリアに追加
git commit -m "メッセージ"：ステージにある変更を「コミット」として確定し、ローカルリポジトリに履歴として保存

コミットメッセージは、後から見ても内容が分かりやすいように「何を変えたか」「なぜ変えたか」を簡潔にまとめると、チーム内での共有や自分自身の記憶補完に役立ちます。

3.4 git push

git push [リモート名] [ブランチ名]：ローカルリポジトリの変更（コミット履歴）をリモートリポジトリへ反映
一般的には git push origin ブランチ名 などのように使われる

プッシュする前に必ずローカルでコミットを行っておきましょう。コミットされていない変更はローカルに留まったままです。

3.5 git pull / git fetch

git pull [リモート名] [ブランチ名]：リモートリポジトリの最新変更をローカルに取得して、自分のブランチへ自動的にマージ
git fetch [リモート名] [ブランチ名]：リモートの最新履歴のみを取得（ローカルのブランチにはマージしない）

pullを使うと一気にマージまで行われますが、何が更新されたか確認してからマージしたい場合はfetchを使って差分を確認した後に自分でマージする方が安心です。

4. 具体的な作業フロー

初心者のうちは特に流れを押さえておくことが大事です。以下のような手順が一般的な開発フローの一例となります。

リポジトリをクローンする：プロジェクトを初めて扱うときはまずgit cloneでローカルに落とす
ブランチを作成して移動：git checkout -b feature/new-function など、新しい機能や修正ごとにブランチを切る
編集→add→commit：作業内容をこまめにコミットし、変更点を細かく管理
最新のリモート変更を取り込む：定期的にgit pullなどで自分が知らない他の開発者の変更を反映し、コンフリクトを最小限に抑える
プッシュしてPull Requestを送る：作業完了後はgit push origin feature/new-functionのようにリモートへ反映し、GitHub上などでPull Requestを作成
コードレビューを受け、問題なければマージ：レビューコメントを反映した上でメインブランチに統合し、不要になったブランチは削除

これらのステップを踏むことで、複数人が同時に開発をしていても、どこで何が変更されているのかが明確になり、レビューやテストが行いやすくなります。

5. ソースツリー(SourceTree)との使い分け

Gitを扱う上で、コマンドラインだけでなくGUIツールを利用するケースも多いです。その中でも特に有名なのが「SourceTree」というアトラシアン(Atlassian)社が提供している無料ツールです。

5.1 SourceTreeのメリット

視覚的に操作しやすい：GUIにより、ブランチの分岐や履歴がツリー形式で表示されるため、どこで分岐したか一目瞭然です。
ドラッグ＆ドロップの操作：ブランチを切り替えたり、コミットの内容を確認したりする操作がボタンやドラッグ操作で完結できることもあるため、初心者に優しい。
各種ホスティングサービスとの連携が容易：GitHubやBitbucket、GitLabなど主要なリモートリポジトリと連携する機能が標準で用意されています。

5.2 コマンドラインとSourceTreeの使い分け

コマンドライン（CLI）の利点
- 1行の入力で操作が完結するため、慣れると非常に高速にGit操作が行えます。
- サーバー上での作業やCI/CDパイプラインの設定など、GUIが使えない環境でも同じ知識を活用できます。
- Gitコマンドそのものへの理解が深まり、トラブルシューティング能力が高くなります。
SourceTreeの利点
- 直感的に履歴やブランチを把握しやすいので、チームの状況確認が簡単。
- コミットの差分を見やすい画面でまとめて確認でき、コンフリクト解消の手助けとなる機能も充実。
- Gitコマンドをすべて覚えていなくても操作しやすい。初心者が最初に習得するにはとっつきやすい面があります。
併用する場合のコツ
- GUIツールだけに頼るのではなく、CLIでの基本操作も並行して学んでおくと、いざという時に対処しやすくなります。
- 大きなリポジトリや多数のブランチがあるプロジェクトでは、SourceTree側での描画が重くなる場合があるため、そのような場面ではCLIが便利です。
- 定型的な操作（コミットやプッシュ、プル）をSourceTreeで行いつつ、トリッキーな作業（リベースやコンフリクト時の詳細調整など）はCLIで行うなど、状況に応じて使い分けましょう。

6. 実務で気をつけたいポイント

初心者が実際の現場でGitを使い始める際に、特に注意しておきたい点をいくつか挙げます。

コミットは小さく・こまめに
- 1つのコミットが大きすぎるとレビューしづらく、問題が起きた時に原因を特定しにくくなります。
コミットメッセージは簡潔かつ明確に
- 「修正」や「変更」だけでは後で内容を把握しづらいので、「Login APIの認証方式をOAuth2に変更」など何をやったかがわかるようにしましょう。
定期的にリモートをプルしてコンフリクト予防
- 共同開発では他のメンバーが頻繁にコードを変更しているため、こまめにpullして差分を取り込みながら作業した方が大きなコンフリクトを避けられます。
メインブランチを直接いじらない
- mainやmasterブランチは製品版や共有で使われる最も重要なブランチです。基本的に直接コミットせず、ブランチを切ってPull Requestでレビューを経てマージするのがセオリー。
不要なファイルは.gitignoreに設定
- ビルド成果物や個人の設定ファイル（IDEのキャッシュなど）はコミット対象から外し、リポジトリをクリーンに保ちましょう。
レビューを習慣化し、品質を担保
- Pull Requestを出したらチームメンバーからコードレビューを受けること。自分も他の人のプルリクを見て学習し、フィードバックの練習をしましょう。

7. GitのBranch戦略の概要

現場によっては、Git-FlowやGitHub Flowなど、特定の運用ルールが定まっている場合があります。たとえばGit-Flowでは、以下のようなブランチ構造を取るのが一般的です。

main（master）ブランチ：常にリリース可能な状態のコードを置いておく
developブランチ：次のリリースに向けた開発を行うブランチ
featureブランチ：機能追加や改善を行うための短期的なブランチ。完了したらdevelopに統合
releaseブランチ：リリース直前の調整やバグ修正を行う
hotfixブランチ：本番リリース後に緊急で修正が必要な場合に使う

一方、GitHub Flowはよりシンプルで、mainから直接ブランチを切ってPull Requestで開発内容をレビュー＆マージする形です。プロジェクトやチームの規模、運用ポリシーに応じて最適な戦略は変わるため、事前にチーム全員で方向性を共有しておくとスムーズに進行できます。

8. よくあるトラブルシューティング

8.1 コンフリクト（Conflict）の解消

複数人が同じファイルの同じ行を修正したり、ファイル構造の変更が重なったりすると、Gitが自動でマージできなくなります。これをコンフリクトといいます。

pullまたはmergeの際にコンフリクトが起きると、該当箇所が<<<<<< HEADや>>>>>>> branch_nameのようなマーカーで示されます。
エディタやSourceTreeのコンフリクト解消画面などで、どの部分を採用するか、あるいはどのように統合するかを人間が手動で決定します。
解消後は再度コミットしてプッシュし、コンフリクトを解決した履歴として残します。

8.2 force push（–forceオプション）による履歴破壊

git push -f（または--force）は、リモートブランチの履歴を強制的に上書きする操作です。
運用ルール次第では必要な場面もありますが、他の人のコミットを巻き戻したり、レビュー中の履歴が変わったりする可能性があるため、安易に使うと混乱の原因になります。
プロジェクトの規模やチームの慣習にもよりますが、多くの場合は--force-with-leaseを使うなど、ある程度の安全策を講じるか、もしくはチームで許可が下りた場合にのみ行うようにしましょう。

8.3 大容量ファイルの管理

Gitは基本的にテキストベースの差分管理が得意ですが、画像や動画など大容量バイナリファイルを直接管理するとリポジトリ容量が大きくなりがちです。
そのような場合はGit LFS（Large File Storage）などの拡張機能を活用し、大容量ファイルを効率よく扱う仕組みを整えることを検討しましょう。

9. まとめ

本稿では、初心者エンジニアが現場で最低限知っておくべきGitの基本操作や重要概念に加え、SourceTreeとの使い分けについても解説しました。

Gitの基礎：clone / add / commit / push / pull といったコマンドの動作を理解する
ブランチ活用：mainブランチを壊さないように安全に開発できる
SourceTreeのメリット：視覚的にわかりやすく、初心者でも直感的に操作しやすい
CLIとの使い分け：大規模リポジトリやサーバー操作にはコマンドラインが必須となる場合も
実務でのポイント：コンフリクトを避けるためにこまめにプル、コミットは小まめに、レビュー習慣を大切に

Gitは一見すると覚えるコマンドが多く、概念も複雑に見えますが、一度フローを身につけてしまえば世界中のソフトウェア開発現場で通用するスキルとなります。最初はGUIツールで操作を理解しつつ、慣れてきたらCLIの基本も押さえることで、あらゆる環境で柔軟に対応できるようになるでしょう。自分で何度も操作を繰り返し、ブランチを切ったり差分を確認したりと、手を動かしながら体に馴染ませていくことが最短の習得方法です。これから現場で活躍するエンジニアとして、ぜひ本稿の内容を土台にGit運用をマスターしてください。