Gitの勉強会用の資料 Gitの勉強会用ページ http://irobot.csse.muroran-it.ac.jp/index.php?%A5%BC%A5%DF%A4%CE%A4%AA%CF%C3%2F%B0%EC%CD%F7%2Fgit

1. Git Lev.1 -おひとりさま用-
倉重健太郎
2015 年 5 月 14 日
1 前提
本資料は，万人向けの資料ではなく，以下の使用状況下を想定した資料である．
• Git サーバとして GitLab を用いる．特に，以下のどちらか (もしくは両方) を想定している．
– 研究室に自前の GitLab サーバを構築している．
– GitLab.com にアカウントを持っている．
2 概要
図 1 Git & GitLab の全体像
1

2. Git と GitLab の概要図を Fig.1 に示す．ローカル PC には管理対象となるファイル群 (target) があり，現
在の情報がユーザから見える．ユーザに見えているファイル・ディレクトリをワークツリー (work tree) とい
う．target のトップディレクトリに.git/ディレクトリ (レポジトリ) があり，この中に git によって記録された
target のスナップショットがある．基本的に target のスナップショットをリポジトリ (repository) という．
さらに，ワークツリーにある各ファイルに対して，git で管理するのか，管理しているならいつスナップショッ
トをとって現在の状態と同じなのか，といった情報を保持しているものがインデックス (index) である．
Figure 1 をもとに説明すると St は t 番目にとったスナップショットを表す．例えば S1 は最初にとったス
ナップショット，即ち最も古い target の状態であり，St は一番最近にとったスナップショット，即ち最も新
しい target の状態である．ただし，本当に一番最新の状態は，リポジトリの中の St ではなく，ワークツリー
のファイル群である．
この資料では Git および GitLab を一人で使用する際の最も基本的な操作について説明する．詳しいものに
ついてはネット上に沢山あるので必要に応じて調べるものとし，ここでは大まかな流れを理解することを第一
目的とした．
3 基本操作
この資料では git init/clone/add/mv/rm/commit/status/remote/push のコマンドについて簡単な説明を
行う．
3.1 準備に関わるコマンド
git init
管理対象となるファイルのあるディレクトリで実行することで，git 管理のための初期化を行う (プロ
ジェクトの作成を行う)．既にローカル PC にファイルがあり GitLab にはプロジェクトがない場合に
このコマンドを使用することになる．
git clone url
url:リポジトリの url
プロジェクトを設置したいディレクトリ (の親ディレクトリ) で実行することで，GitLab 上のプロジェ
クトをローカル PC に持ってくる．既に GitLab にプロジェクトがありローカル PC に管理対象となる
ファイルがない場合にこのコマンドを使用することになる．
3.2 ファイル操作に関わるコマンド
git add [option] file
[option]:-u:変更のあったファイル全て．:git add -u, git add -u *.txt
file:対象ファイル．”.”ですべてのファイル．:git add test.txt, git add .
管理対象ファイルとしてインデックスに登録する．または管理対象ファイルに変更があった場合，「変
更があった」と認識 (そのようにインデックスを変化) する．
git mv source target
例:git mv a.txt b.txt
2

3. ファイル名を変更する．git mv ではなく mv を使ってしまうと git がファイル名の変更を追跡できな
い．例えば，mv a.txt b.txt としてしまうと，git からは a.txt が消えて b.txt が管理対象外の新しい
ファイルとして出現したように見える．ちなみに mv a.txt b.txt としてしまったら git add b.txt とす
れば勝手に「b.txt は a.txt の名前が変わったもの」として認識してくれる．
git rm [option] file
[option]:なし, -r:ファイルを削除．-r はディレクトリ全体を消す場合．:git rm test.txt, rm -r dir
[option]:--cash:インデックスから削除．つまり管理対象から外す，という意味．実際のファイルは削除
されない．:git rm --cash test.txt
ファイルを削除する．git rm ではなく rm を使ってしまうと git がファイルの削除を追跡できない．間
違えて rm を使ってしまったら git add -u .(変更したファイル全部をインデックスに追加) を行うと
「delete されているファイルをインデックスに追加」ということで git rm と同じ状態に出来る．
3.3 ローカル PC の管理に関わるコマンド
git commit [option]
[option]:なし:インデックスにもとづいてワークツリーをリポジトリに保存．
[option]:-a:ワークツリー内の変更を自動検出し (git add . の実行と同等)，リポジトリに保存．
[option]:-m ”メッセージ”:リポジトリに保存する場合のコメントを登録．
commit はインデックスにもとづいてワークツリーをリポジトリに保存する．そのため，あるファイル
を変更しても，「変更した」とインデックスが知らなければ (git add あるファイルをしていなければ)
そのファイルはリポジトリに保存されない．変更分すべてをリポジトリに保存したければ，git add .;
git commit とするか，git commit -a と実行しなければいけない．逆にいうと，色々変更しているがリ
ポジトリに保存したいものはちゃんと動くことが確認されたファイルのみ，などリポジトリに保存した
いファイルを指定できる．また-m ”メッセージ”は省略するとメッセージを入力するためのエディタが
起動する．
git status
git の管理状態を表示する．使用頻度高い．
3.4 サーバとのやりとりに関するコマンド
git remote [option]
[option]:add name url:長∼い url に短∼い name という別名を付与．:git remote add origin
git@gitlab.com:kentarou/git seminar.git
[option]:-v:登録一覧を表示．
[option]:-r name:name を登録一覧から削除．
git push などでサーバ上にあるプロジェクトをやりとりする場合が多いが，この時に長い url を使いた
くない．git remote add で短い名前を登録することで，長い url の代わりに短い name を使用すること
ができる．origin は習慣としてよく使われる名前である．
git push [option] [リポジトリ名 [ローカルブランチ名:リモートブランチ名]]
3

4. [リポジトリ名]:リポジトリ名．url でも git remote で設定した短縮名でもよい．リポジトリ以下を省略
した場合の挙動は push.default による．
push.default による挙動の違い．
nothing:リポジトリ名以下を省略できない．:git push origin master:master など．
matching:ローカルとリモートで同じブランチ名のもを「すべて」push する．現在のブランチだけでな
くそれ以外も push されるので注意が必要．
upstream:upstream が設定されていれば (後述の-u を参照)，設定された追跡しているブランチを push．
simple:カレントのブランチに追跡ブランチが設定されており (upstream の設定)，かつローカルとリ
モートでブランチ名が同じ場合，それを push.
current:カレントと同名のブランチがあれば，そこに push.
[ローカルブランチ名:リモートブランチ名]:対象のブランチ名．設定する場合，リポジトリ名必須．
ブランチ名を設定．master，のようにひとつだけだとローカル・リモート両方を master ブランチ名と
して push を試みる (?)．:master，のようにリモートだけ設定した場合，「空のブランチをリモートの
master に push する」という意味でリモートのブランチを削除することとなる．通常，master:master
のように両方指定する．
例 1:git push git@gitlab.com:kentarou/git seminar.git master:master
例 2 remote で origin と短縮名を登録している場合．:git push origin master:master
例 3 上記かつ現在のブランチを push．:git push origin master
ローカル PC からサーバへのアップロードは push として紹介した．サーバからローカル PC へのダウン
ロードは fetch や pull などあるが，とりあえず「タイワークツリーを削除 (or project.bk などディレクトリ名
を変更) し，git clone してしまえばサーバ上の最新プロジェクトにすることが出来るので割愛した (後述)．
3.5 Git での管理開始手順
3.5.1 ローカル PC から始める場合の手順
ローカル PC 上に既に管理したいファイル群がある場合の基本的な手順を述べる．
それらファイル群のあるトップディレクトリを˜/project/とする．GitLab にアップロードすることを考え，
まず GitLab でプロジェクトを作成する．プロジェクトの名前はトップディレクトリの名前と同じにするこ
と．またプロジェクトの作成方法は各自調べること．
$ cd ˜/project/
$ git init
$ git add .(個別のファイルを追加したい場合は. の代わりにファイル名)
$ git commit -m ”コメント．first commit とか”
$ git remote add origin url (url は GitLab のプロジェクトの url)
$ git push -u origin master
GitLab でプロジェクトを作成すると上記に似た手順を「ローカル PC で以下の手順を行ってください」の
ようなメッセージとともに手順一覧が表示される．その中に url が含まれているので git remote 実行時の参
考とする．
4

5. 3.5.2 GitLab 上にあるプロジェクトから始める場合の手順
GitLab 上に既にプロジェクトが存在し，ローカル PC には何もない状態から始める手順を述べる．例とし
て GitLab 上のプロジェクト名を test，その url を git@gitlab.com:kentarou/test.git とする．
$ cd ... (プロジェクトを置きたいディレクトリ)
$ git clone git@gitlab.com:kentarou/test.git
3.5.3 サーバにもローカルにもプロジェクトがなく新しく始める場合
まず GitLab 上にプロジェクトを作る．そうすると「ローカル PC で以下の手順を行ってください」のよう
なメッセージとともに手順一覧が表示されるので実行すればよい．基本的には以下のものが表示されるはず．
$mkdir test
$cd test
$git init
$touch README.md
$git add README.md
$git commit -m ”first commit”
$git remote add origin git@gitlab.com:kentarou/test.git
$git push -u origin master
3.6 Git での通常管理
基本的に自分の好きなエディタ等で編集すればよい．で，一段落ついたら，
• $ git commit -a -m ”コメント”
少し慣れてきたら，
• $ git add commit したいファイル
• $ git commit -m ”コメント”
add と commit の簡単な関係を Fig.2 に示す．また，ファイル操作は git mv/rm を使用する．
GitLab にアップロードしたい段階で，
• $ git push orign master (-u 使っていたら git push)
ちなみにアップロードされるのはローカル PC のリポジトリである．よって，ローカルでの変更履歴も全て
GitLab にアップロードされる．このことから一日の終わりとか，他の人が「きみのアップしてよ」のタイミ
ングとかでよい．
5

6. 図 2 Git の add と commit の関係
3.7 GitLab とのやりとり
GitLab にアップロードするには push を使うが，GitLab からローカル PC にダウンロードするには以下の
方法がある．
• git clone url 等
• git fetch url や name など
• git pull url や name など
git fetch や git pull は，ローカル PC と GitLab それぞれにプロジェクトで出来ており，GitLab 上のプロ
ジェクトの方が最新の場合に，ローカル PC に最新の情報を取り込む為に使われる (図 3)．が，git clone を用
いた以下の手順で可能なため，説明を省く．fetch, pull については必要に応じて調べて使用していけばよい．
• プロジェクトのディレクトリを削除．もしくはディレクトリ名を変えてバックアップ
• git clone で対象プロジェクトをダウンロード
6

7. 図 3 GitLab とのやりとり
4 基本運用
運用は，それぞれの使用環境で変わる．ここでは，倉重研究室の運用を基本として述べる．
4.1 commit, push のタイミング
git はバージョン管理システムであり，バックアップアプリケーションではない (としても勿論使えるが)．
よって，以下を念頭において使うこととする．
• 動作するものを commit, push すること．
• コメントは前からの変化を記述し，バージョン番号などは書かないこと．
例えばプログラムのソースであればコンパイルし実行することが可能なものを指す．バグがあっても動くな
らばとりあえず commit,push(してコメントに記述) すればよいが，バグがないけど作ってる最中で完成して
いないならば commit,push してはいけない．
またコメントに関しては，古いバージョンに戻りたいときに指針となる内容を書くべきである．ちなみに
バージョン番号は，コメントとしてではなくタグとして記述すべきである．タグ名を使って古いバージョンに
戻れるので，バージョン番号はタグに合っている．また，今回は説明していないがブランチ機能を使うと様々
な履歴の取り方が出来る．その場合，コメントに統一的なバージョン番号を書くこと自体が出来なくなってし
まう．
4.2 Git での管理終了
管理しているプロジェクトが終了したり不必要になった場合，基本ほっといてよい．ほっとく以外に次のこ
とをしてもいいかもしれない．
ローカル PC のプロジェクトを消去
最終版を commit しサーバに push 後，ローカル PC のプロジェクトをディレクトリごと消去する．
サーバにプロジェクトが残っているので，必要になったら clone すればよい．
7

8. サーバのプロジェクトを消去
サーバのプロジェクトを消去する．サーバ上で必要になったらローカル PC に残っているプロジェクト
再アップロードすればよい．ローカル PC のプロジェクトは NAS かなんかに保存しておいてもよい．
ローカル PC のプロジェクトもサーバのも消去
本気でいらなくなったら全部消してしまえ．
8