リポジトリとは? ローカルリポジトリとリモートリポジトリの違いと役割を解説

バージョン管理システムの Git は、現代のソフトウェア開発には欠かせないツールです。

Git を使いこなすには、まず「リポジトリ」を理解することが重要です。

この記事では、Git 初心者の方に向けて、リポジトリの種類や基本的な操作方法をわかりやすく解説していきます。

本記事で解説するリポジトリ操作

  • Gitの初期化
  • ローカルリポジトリの操作
    • リポジトリの作成
    • 編集からコミットまで
    • チェックアウトによる並列作業
  • リモートリポジトリの操作
    • ローカルからリモートへのリポジトリの反映
    • その逆(リモートからローカルへ反映)

この記事の内容を理解すれば Git を使うシーンの大半の操作はできるようになります

最後まで読んで、Git の基本を理解しましょう。

目次

はじめに:バージョン管理と Git

ファイルを編集していると、「前のバージョンに戻したい!」と思うことはありませんか? バージョン管理システムは、ファイルの変更履歴を記録し、過去の状態に戻したり、変更箇所を比較したりすることを可能にします。

Git は、現在最も広く使われているバージョン管理システムの一つです。高速で柔軟性が高く、分散型という特徴を持つため、多くの開発現場で採用されています。

Git の特徴

CVS や Subversion などの従来のバージョン管理システムは、集中型バージョン管理システムです。 中央のリポジトリにすべての変更履歴が保存され、開発者はそのリポジトリからファイルをチェックアウトして作業し、変更をコミットします。

体験談

このチェックアウトが厄介で、

このファイルに修正を加えなきゃ

と思ってチェックアウトしようとしたときに、他人が別の目的で修正するためにチェックアウトしており、

A さんがチェックアウトしてるから修正終わってコミットするまで待とう

というコンフリクトがよくありました。

一方、Git は分散型バージョン管理システムです。 各開発者がリポジトリの完全なコピーをローカルに持つため、オフラインでも作業ができ、中央リポジトリに依存しません。

リポジトリ

そのため、Git はバージョン管理が非常に軽量で高速です。 大規模なプロジェクトではパフォーマンスが低下することはありません。

また修正対象を事前にチェックアウトするのも不要です。 なので、修正し始めるときには他人の修正とコンフリクトすることはありません。 修正が終わり、反映するときに初めてコンフリクトが発生します。 (同じ箇所を2人で修正した場合だけですが)

修正し始めるときは、最終的にそのファイルの修正が正しいかわからないので、反映するときにコンフリクトするのは実に合理的です。

リポジトリの種類

Git リポジトリとは、ファイルやディレクトリの状態を記録する場所です。 リポジトリに保存された状態は、変更履歴として格納され、バージョン管理を行うことができます。

Git のリポジトリには、大きく分けて「ローカルリポジトリ」と「リモートリポジトリ」の 2 種類があります。

  • ローカルリポジトリ: 自分の PC に作成されるリポジトリです。編集作業は基本的にこのローカルリポジトリで行います。
  • リモートリポジトリ: サーバー上にあるリポジトリです。複数人で共同作業する場合や、バックアップとして利用します。GitHub が有名です。

リポジトリ

リモートリポジトリの代表的なサービスとして、GitHub が挙げられます。 GitHub は、Git リポジトリをホスティングするサービスで、世界中の開発者が利用しています。

私もプライベートなソースコードはGitHub(crz33)で管理しています。

Git を使う準備

Git を使うには PC に Git クライアントがインストールされていることが必要です。

Windows であれば Git for Windows をインストールするのが通常です。 ですが、筆者は Windows Subsystem for Linux (WSL) を使うのをおすすめします。

WSL は Windows 上で Linux を直接実行できる機能です。 Git for Windows バージョン管理で Git を使う目的は、プログラム開発だと思いますので、WSL を使って開発環境と一緒に Git を準備するのがよいでしょう。

この記事で、Python の開発環境を例に WSL のセットアップ方法を紹介しているので、参考にしてください。

あわせて読みたい
Python プログラミングの始め方 本記事では Python の開発環境の構築方法を紹介します。 Python の開発環境の作り方はいくつかの方法がありますが、おすすめは WSL を使った方法です。 私はプログラミ...

Git の初期化

Git には、git config と呼ばれるツールが付属しています。 これにより Git の機能するかを制御できる設定を管理できます。

これらの設定は3つの異なる場所に格納されます。 細かいですが、困ったときのために紹介しておきます。 「この動きって、どこに設定されてるの?」となったときに思い出してください。

  • システムごとの設定(system) : Linux であれば /etc/gitconfig、Git for Windows であれば C:\Program Files\Git\mingw64\etc\gitconfigにあります。
  • ユーザごとの設定(global) : Linux であれば ~/.gitconfig に、Git for Windows であれば C:\Users\${ユーザ}\.gitcocnfig にあります。
  • リポジトリごとの設定 : Linux、Git for Windows ともにリポジトリのディレクトリの.git/config にあります。

この3つの設定は、同じものがあれば、下から優先です。

Git をこれから使い始めるときには、これから説明する3つを設定しておきましょう。

  1. Github などの共有リポジトリにアクセスするための個人の識別情報
  2. コミットログなどを編集するときに使うエディター
  3. リポジトリ作ったときのデフォルトブランチ名

リポジトリごとに設定もできますが、たいていは共通なので「ユーザごとの設定(global)」として設定しておくと便利です。

1. 個人の識別情報

Github などの共有リポジトリにアクセスするための個人の識別情報として、ユーザ名とメールアドレスを設定します。 設定方法は以下のとおりです。

git config --global user.name ユーザ名
git config --global user.email メールアドレス

2. エディター

今後、編集をコミットするときにコメントを書くことになります。 そのときのエディタを設定します。

git config --global core.editor vim

3. デフォルトブランチ

Git でリポジトリを作ったときのデフォルトのブランチ名は master ですが、諸事情で Github などのサーバのデフォルトの名前は main になりました。 Github と一緒の名前にするために以下のようにして変更しておきます。

git config --global init.defaultbranch main

リポジトリの基本操作

ここからは、以下の3つのリポジトリ操作を実戦形式で解説していきます。

3つのリポジトリ操作

  1. チェックアウト : リポジトリの内容を作業ディレクトリへ反映
  2. ステージング : 編集内容をステージエリアへ登録
  3. コミット : ステージエリアの状態をリポジトリへ反映

リポジトリ操作

実際に Git を使うときに必要となる基本コマンドをすべて取り上げているので、使い始めるにあたっては、この記事の内容で十分です。

図のとおり、まずはリモートリポジトリには関係ないローカルリポジトリのみの操作を解説します。

ローカルリポジトリの作成

Git でファイルを管理するには、まずリポジトリを作成する必要があります。 ローカルリポジトリを作成するには、git init コマンドを使用します。

適当なディレクトリを作って、git init します。

$ mkdir git_handson
$ cd git_handson/
$ git init

このコマンドを実行すると、カレントディレクトリに .git という隠しフォルダが作成され、リポジトリとして初期化されます。

編集内容のステージング

リポジトリは空の初期状態なので、「1.チェックアウト」はできません。

編集の例としてREADME.mdを作成してみましょう。

$ echo "# Hands-on : Git" > README.md

これで空の状態から README.md が追加された状態になりました。

git status で状態を確認してみましょう。

$ git status
On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        README.md

nothing added to commit but untracked files present (use "git add" to track)

出力内容のとおりですが、説明しておきます。

  • “No commits yet” : まだコミットはなく、
  • “Untracked files: README.md” : トラッキングしてないファイルとして README.md がある

トラッキングしていない(Untracked)とは、「リポジトリから変化しているけど、まだステージングもされていなくて記録できていないよ」という意味です。

では、Untracked な状態の README.md をステージングしましょう。 ステージングするには git add します。

$ git add README.md

README.mdをステージングできたら、もう一度、状態を確認しましょう。

$ git status
On branch main

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
        new file:   README.md

Changes to be committed(コミットされる変更)として、new README.mdが記録されました。

ステージングの内容をコミット

先ほどステージングしたREADME.mdをコミットします。 コミットのコマンドはgit commitです。

$ git commit -m "add README"
[main (root-commit) 9700cfd] add README
 1 file changed, 1 insertion(+)
 create mode 100644 README.md

リポジトリの内容のチェックアウト

ここまでで、

  • 空のリポジトリを作成: git init
  • 編集(README.md を追加)
  • README.mdの追加をステージング: git add
  • ステージング内容をコミット: git commit

を実践しました。

ここからは、以下のリポジトリの基本操作の「チェックアウト」の説明をしていきます。

リポジトリ操作

チェックアウトは「リポジトリ(or ステージング)」の内容を作業ディレクトリへ反映することです。

チェックアウトは、ステージングやコミットに比べ、少し理解が難しいので、編集のシナリオに沿って解説します。

編集のシナリオ

あなたは、次の2つの修正依頼を、同時に進めなければいけません。

  • README.mdを編集して、内容を充実してほしい。
  • .gitignoreファイルを追加してほしい。

では、このシナリオに沿って実践し、チェックアウトについて理解しましょう。

作業用ブランチを作成

2つの作業用ブランチを作成します。 ブランチについては、ここでは詳しく解説しませんが、「作業用の小さなリポジトリ」だと理解して実践してください。

ここまでで、一度コミットしたので、mainブランチができています。 ブランチの確認はgit branch -aです。

$ git branch -a
* main

mainブランチができていますね。

ではこのmainブランチをベースとした作業用のブランチを2つ作ります。 ブランチの作成はgit branch [new branck name]です。

$ git branch work-readme
$ git branch work-gitignore

git branch [new branch name]で作った場合、ベースになるのはコマンドを実行したときにチェックアウトしていたブランチです。 上記でコマンドを実行したときは、リポジトリにはmainブランチしかないので、2つともmainブランチから作成したことになります。

もう一度ブランチを確認してみましょう。

$ git branch -a
* main
  work-gitignore
  work-readme

作成した2つのブランチができています。 また、現在mainブランチをチェックアウトしていることがわかります。

では、シナリオに沿って編集していきます。

README.mdを編集とコミット

まずはREADME.mdを編集するために作ったブランチwork-readmeをチェックアウトします。

$ git checkout work-readme
Switched to branch 'work-readme'

このwork-readmeは、先ほどまで作業していたmainブランチをベースに作ったので、作業ディレクトリの内容に変化はないです。 lscatでファイルや中身を確認してみてください。

確認できたら、README.mdを編集します。

$ echo "Hello world." >> README.md

$ cat README.md
# Hands-on : Git
Hello world.

README.mdに1行追加しています。 編集できたら、ステージング・コミットしてリポジトリに登録します。

$ git status -s
 M README.md

$ git add README.md
$ git commit -m "update README"
[work-readme 4e52b74] update README
 1 file changed, 1 insertion(+)

これで、work-readmeでのREADME.mdの編集は片付きました。

シナリオとしては、いったんこの編集作業は置いといて、別の編集作業(.gitignoreの追加)を始めます。

.gitignoreの追加とコミット

最初に.gitignoreの作成用にブランチwork-gitignoreを作っておいたので、そのブランチをチェックアウトします。

$ git checkout work-gitignore
Switched to branch 'work-gitignore'

試しにREADME.mdの中身を確認してみます。

$ cat README.md
# Hands-on : Git

先ほど、README.mdを編集したwork-readmeの内容ではなく、ブランチを作成した直後の内容になってます。 work-gitignoremainブランチをベースに作ったので、作業ディレクトリの中身がその状態に切り替わりました。

この「作業ディレクトリをリポジトリの内容に置き換える・切り替える」がチェックアウトです。 これで、チェックアウトの実践としてはできましたが、慣れるためにもう少し進めましょう。

シナリオ通り、.gitignoreを追加して、リポジトリにコミットします。

$ echo ".env" > .gitignore
$ git add .gitignore
$ git commit -m "add .gitignore"
[work-gitignore a1987ff] add .gitignore
 1 file changed, 1 insertion(+)
 create mode 100644 .gitignore

この後、README.md編集用のブランチに戻るため、チェックアウトしますが、その前にファイルの一覧を確認しておきます。

$ la -a
.  ..  .git  .gitignore  README.md

追加した.gitignoreがありますね。

README.mdの編集作業に戻る

README.md編集用のwork-readmeに戻るためチェックアウトします。 チェックアウトして、ファイルを確認しましょう。

$ git checkout work-readme
$ ls -a
.  ..  .git  README.md

work-gitignoreでは追加した.gitignoreはないですね。 作業ディレクトリがリポジトリのwork-readmeの内容に切り替わりました。

しばらく、今回、作成した2つのブランチwork-readmework-gitignoreをチェックアウトしつつ、ファイルがどう変わるか確認してみてください。 これがチェックアウトです。

チェックアウトのまとめ

2つのブランチを作って、チェックアウトしながら編集しました。

チェックアウトは、次の図のようにリポジトリの内容を作業ディレクトリに反映する・切り替えることを言います。

チェックアウト

開発現場ではチェックアウト必須

実際のGitを使ったチーム開発では、「機能追加」や「不具合対応」など、複数の編集作業を平行します。 このチェックアウトを多用してバージョン管理することになります。

システムエンジニアを目指すのであれば、複数ブランチでのチェックアウトの操作に慣れることは重要です。

変更のマージ

先ほどのシナリオでは、別の編集目的で2つブランチを作り、編集作業を進めてきました。

リポジトリ操作の「マージ」もこのシナリオを使って実践しなたら解説します。

シナリオ

以下の2つの編集が終わったので、もともとのmainブランチに各編集内容をマージする。

  • README.mdを編集 : work-readme
  • .gitignoreを追加 : work-gitignore

まずは、マージ先のmainブランチをチェックアウトして作業ディレクトリをmainに切り替えます。

$ git checkout main

マージ先のmainをチェックアウトできたら、work-readmeのブランチの内容を(現在のブランチ:mainに)マージします。

わかりやすくするために、事前にREADME.mdを確認してからマージします。

$ cat README.md
# Hands-on : Git

$ git merge work-readme
Updating 9700cfd..4e52b74
Fast-forward
 README.md | 1 +
 1 file changed, 1 insertion(+)

$ cat README.md
# Hands-on : Git
Hello world.

ちゃんと、README.mdを編集した内容を取り込むことができました。

次に、work-gitignoreのブランチの内容を(現在のブランチ:mainに)マージします。

わかりやすくするために、事前にls -aでファイルを確認してからマージします。

work-gitignoreがベースとしていたmainブランチの内容が進んでいるので、マージするときにコミットメッセージを求められます。 デフォルトのコミットメッセージでよいので、vim であれば:wqで保存して終了します。

$ ls -a
.  ..  .git  README.md

$ git merge work-gitignore
Merge made by the 'ort' strategy.
 .gitignore | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 .gitignore

$ ls -a
.  ..  .git  .gitignore  README.md

.gitignoreを追加した編集内容を取り込むことができました。

これで、ブランチを作って編集作業していた内容を元のブランチにマージできました。

リモートリポジトリの操作

ここまでは、自分の PC のローカルリポジトリの操作を解説してきました。 ここからはリモートリポジトリの操作を、以下の順で解説していきます。

リモートリポジトリの操作

  1. リモートリポジトリの作成
  2. ローカルリポジトリにリモートリポジトリを設定
  3. ローカルリポジトリをリモートリポジトリへ反映

リモートリポジトリとローカルリポジトリで以下の操作をします。

リモートリポジトリ

では、実際にやってみましょう。

リモートリポジトリの作成

GitHub でリポジトリを作成してください。

これからローカルリポジトリの内容を反映するので、リポジトリ作成時には何も含めず空のリポジトリで作成します。 以下のの画面のように作れば、空のリポジトリで作ることができます。

GitHubリポジトリ

ローカルリポジトリでの操作

先ほど作成した GitHub のリポジトリをローカルリポジトリのリモートとして登録します。

$ git remote add origin git@github.com:crz33/git_handson.git

登録したリモートはgit remoteで確認できます。

$ git remote -v
origin  git@github.com:crz33/git_handson.git (fetch)
origin  git@github.com:crz33/git_handson.git (push)

GitHub リポジトリをリモートとして登録できたので、それを使って、ローカルのリポジトリを反映します。 ローカルからリモートへはgit pushで実施します。

$ git push -u origin main

反映結果は GitHub 側で確認できます。 ローカルリポジトリで作成したファイルが反映されていますね。

反映結果

“ローカルリポジトリを反映した”わけなので、コミットやメッセージも GitHub へ反映されています。

コミットログ

逆にリモートからローカルへはgit fetchで反映できます。

$ git fetch

まとめ

この記事では、Git のリポジトリについて、その種類、基本的な操作方法を解説しました。リポジトリは Git の基礎となる概念なので、しっかりと理解しておきましょう。

以上です。

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

システム開発の経歴が20年のエンジニアです。
フロントエンド(Ajax,...,React,SPA)からバックエンド(Database,...,Hadoop,PaaS)まで幅広く経験し、現在は企業に勤め、社内のITアーキテクトに就いています。

コメント

コメントする

CAPTCHA


目次