バージョン管理システムの 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 のセットアップ方法を紹介しているので、参考にしてください。

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つを設定しておきましょう。
- Github などの共有リポジトリにアクセスするための個人の識別情報
- コミットログなどを編集するときに使うエディター
- リポジトリ作ったときのデフォルトブランチ名
リポジトリごとに設定もできますが、たいていは共通なので「ユーザごとの設定(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つのリポジトリ操作
- チェックアウト : リポジトリの内容を作業ディレクトリへ反映
- ステージング : 編集内容をステージエリアへ登録
- コミット : ステージエリアの状態をリポジトリへ反映
実際に 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
ブランチをベースに作ったので、作業ディレクトリの内容に変化はないです。
ls
やcat
でファイルや中身を確認してみてください。
確認できたら、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-gitignore
はmain
ブランチをベースに作ったので、作業ディレクトリの中身がその状態に切り替わりました。
この「作業ディレクトリをリポジトリの内容に置き換える・切り替える」がチェックアウトです。 これで、チェックアウトの実践としてはできましたが、慣れるためにもう少し進めましょう。
シナリオ通り、.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-readme
、work-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 のローカルリポジトリの操作を解説してきました。 ここからはリモートリポジトリの操作を、以下の順で解説していきます。
リモートリポジトリの操作
- リモートリポジトリの作成
- ローカルリポジトリにリモートリポジトリを設定
- ローカルリポジトリをリモートリポジトリへ反映
リモートリポジトリとローカルリポジトリで以下の操作をします。
では、実際にやってみましょう。
リモートリポジトリの作成
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 の基礎となる概念なので、しっかりと理解しておきましょう。
以上です。
コメント