【Git】ローカルリポジトリを使いこなす方法を初心者向けに解説
はじめに
Gitはソフトウェア開発で広く利用されるバージョン管理システムです。
特に、ローカルリポジトリを正しく管理できるようになると、自分の手元でコードの変更履歴を自由に扱えるようになります。
開発現場でGitを運用する際、サーバー上のリポジトリとのやりとりはよく話題になりますが、まずはローカル側の基本操作をしっかり理解することが重要です。
この記事では、Gitローカルリポジトリの作成方法やブランチの使い方などを初心者の方でも理解しやすいようにまとめていきます。
「Gitを使い始めたいけれど、どこから手を付ければいいのかわからない」という方の参考になればうれしいです。
この記事を読むとわかること
- Git ローカルリポジトリとは何か
- ローカルリポジトリを作成するための基本的なコマンド
- ローカルブランチの運用と切り替え方法
- コミットやプッシュの流れと実務での注意点
- ローカルで起こりがちな衝突(コンフリクト)の対策方法
Git ローカルとは何か
Gitには大きく分けて、ローカルリポジトリとリモートリポジトリの2つの概念があります。
ローカルリポジトリは皆さんのパソコン(手元)に存在し、コミット履歴などがすべて保存されます。
リモートリポジトリはサーバーやクラウド上に置かれ、チームメンバーと共有されるリポジトリのことです。
まずはローカル側を使いこなせるようになると、安心してコードの修正や試行錯誤ができるでしょう。
ローカルリポジトリの役割
ローカルリポジトリの役割は、手元でコードの変更履歴を管理することにあります。
特に以下のような点が大きなメリットです。
- いつでも変更履歴を振り返ることができる
- 履歴から任意の時点に戻れる
- チームメンバーと連携する前にローカルで検証・整理ができる
このようにローカルリポジトリを賢く使うことで、作業効率が高まり、不要なミスを減らすことにもつながります。
実務での活用イメージ
実務では、まずローカルリポジトリに自分の作業ブランチを作成します。
そこで新機能を実装したり、バグを修正したりするわけです。
十分にテストや確認をした段階で、リモートリポジトリにプッシュし、チームメンバーにレビューしてもらう流れが一般的といえます。
つまり、ローカルリポジトリが作業の基盤になるわけです。
ここをきちんと管理できると、チーム開発でも混乱を減らせるでしょう。
ローカルリポジトリを作成する方法
Gitローカルリポジトリを作る方法として、主に以下の2つがあります。
- 既存フォルダから初期化する
- リモートリポジトリを複製(クローン)する
どちらの方法もよく使われますが、まずは自分でフォルダを作ってみるところから始めるのがわかりやすいかもしれません。
実務では、チームのリモートリポジトリをクローンして作業をスタートすることも多いでしょう。
git init コマンド
新しくプロジェクトを始めるときは、ローカル環境に空のディレクトリを作成してから、以下のコマンドを実行します。
# ディレクトリを作って移動 mkdir my-project cd my-project # git initでローカルリポジトリを初期化 git init
すると、.git
というディレクトリが作成され、ここでGitの情報が管理されます。
このようにしてローカルリポジトリが完成します。
その後は、コードを作成しながらgit add
やgit commit
を利用して変更点を記録していくわけです。
git clone コマンド
チーム開発などですでにリモートリポジトリが存在する場合は、git clone
を使ってリモートをローカルに複製する手順が一般的です。
例えば、リモートリポジトリのURLが https://github.com/example/my-project.git
である場合、次のように実行します。
git clone https://github.com/example/my-project.git
実行すると、my-projectというフォルダが自動的に作られ、そのフォルダの中にローカルリポジトリがセットアップされます。
今後の編集やコミットは、手元のローカルリポジトリで行い、必要に応じてリモートにプッシュする運用です。
ローカルブランチを管理する方法
Gitでは、複数の開発タスクを同時に進めたり、リスクのある変更を安全に試したりするためにブランチを使います。
ローカルでブランチを作成・切り替えを行う方法は非常に簡単なので、早めにマスターしておくと便利です。
ブランチを作成する
新しいブランチを作成するときは、以下のようにコマンドを実行します。
# 新しいブランチ「feature/login」を作成 git branch feature/login
作成後は、git checkout
コマンドを使って、そのブランチに切り替えて作業を進めます。
ただし、最近のGitでは git switch
や git checkout -b
も利用可能です。
# 作成と同時にブランチを切り替える場合 git checkout -b feature/login
ブランチ名は、何を開発しているか分かるようにつけることをおすすめします。
例としては feature/login
, bugfix/header-layout
などが一般的です。
ブランチを切り替える
ブランチを切り替えるコマンドは以下の通りです。
# 既存のブランチに移動する git checkout feature/login
作業を終えてメインブランチ(多くの場合はmain
やmaster
と呼ばれます)に戻す場合も同じコマンドで切り替えます。
切り替え前にコミットやスタッシュを忘れないようにすることがポイントです。
コミットしていない変更があるまま切り替えると、競合が発生する可能性があるため注意が必要になります。
コミットの管理とプッシュ
ブランチを使って開発を進める際には、こまめにコミットしておくと履歴が追いやすくなります。
そして、ある程度まとまった段階やレビュータイミングでリモートリポジトリへプッシュすると、チームメンバーと共有できます。
git commit と git push の流れ
コミットの手順は以下の通りです。
# 変更ファイルをステージングエリアへ追加 git add . # コミットを作成 git commit -m "ログイン機能の画面デザインを作成"
git add .
で、現在のディレクトリ以下の変更をすべてステージングエリアに登録し、その後 git commit
で変更履歴が正式に保存されます。
次に、リモートリポジトリに反映させるには以下のように実行します。
git push origin feature/login
origin
はリモートリポジトリのデフォルト名称、feature/login
はブランチ名です。
ブランチ名を間違えないように指定すれば、自分が作成したブランチをリモート上に新たに作ることもできます。
実務における運用ポイント
実務では、「1つのタスクにつき1ブランチ」 という形で進めることが多いです。
変更内容が増えすぎるとレビューが大変になるため、コミットを分割するタイミングも重要といえます。
コミットメッセージには、何を変更したのかが分かるように短い言葉で書くのがよいでしょう。
コミットメッセージには「画面レイアウト変更」「DBスキーマ修正」など、内容がすぐわかる言葉を入れるとチームメンバーともスムーズに情報共有できます。
ローカルでの衝突(コンフリクト)対策
複数のブランチで同じ箇所のコードを変更すると、いわゆる コンフリクト (衝突) が発生することがあります。
これは、Gitが「どちらの変更を採用すればいいのか分からない」という状態です。
ローカルでコンフリクトが起こった場合は、まず落ち着いて変更が衝突している箇所を確認し、自分の意図する内容を最終的にファイルに反映させます。
その後、再度コミットしてコンフリクトを解消しましょう。
解決方法
典型的な解決手順は次のような流れになります。
- 衝突が発生しているファイルをエディタで開く
- Gitが自動生成したマーカー
<<<<<<<
,=======
,>>>>>>>
を見て、どちらの修正を採用するか決める - マーカーを削除して、問題ない状態にファイルを整える
git add
とgit commit
で修正を反映する
コンフリクトを解決するときは、ファイルの内容が正しく動くかを念入りに確認しながら作業します。
実務では、コンフリクトが出たブランチごとに内容を整理しておき、チームと合意を取ってからコミットを進めることもよくあります。
ブランチを切り替えるタイミングやプッシュの順序を誤ると、想定外のコンフリクトが起きやすくなります。早め早めにプッシュやマージをする習慣をつけましょう。
まとめ
Gitのローカルリポジトリを正しく理解すると、開発の自由度が大きく広がります。
ローカル環境でこまめにコミットして履歴をしっかり管理することで、安心してコードの変更を進めることができます。
また、ブランチを分けて作業すれば、衝突や変更ミスを最小限に抑えられるでしょう。
記事の内容を活用しながら、皆さんのプロジェクトで「Git ローカル」をうまく使いこなしてください。