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.3 -おひとりさまでブランチを-
倉重健太郎
2015 年 5 月 2 日
1 前提
本資料は，万人向けの資料ではなく，以下の使用状況下を想定した資料である．
• Git サーバとして GitLab を用いる．特に，以下のどちらか (もしくは両方) を想定している．
– 研究室に自前の GitLab サーバを構築している．
– GitLab.com にアカウントを持っている．
2 概要
図 1 ブランチの概要
Git にてファイルのバージョン管理を行っていると「安定版」と「機
能どんど追加していく版」に分けたくなったりする．バージョンの流
れを必要に応じていくつか作り，何か変になったら安定版の流れにすぐ
戻せたりできると楽である．このようなバージョンの流れをブランチ
(branch) という．Git ではプロジェクトを最初に作った時に master
という名前のブランチが作成され，master ブランチ上でバージョン管
理が開始される．そして任意の時点で新しいブランチを作ることがで
き，また統合できる．統合とは，二つのブランチを一つにすることで，
それぞれのブランチで行った作業の結果を一つにまとめることである．
もちろん全く異なる進化をとげて内容が全く違うブランチを統合する
ことは困難を極める．しかし一つのプロジェクトから始まっているの
で基本的には同じ目的のものを作っているので，一般に多少の手間で
統合するメリットを大きく得られる．Git におけるブランチの概要を
Fig.1 に示す．
3 基本操作
この資料では git branch/checkout/merge/push のコマンドについて簡単な説明を行う．これらのコマンド
は「HEAD(リポジトリ内の現在の位置)」に対する作業となり，現在のワークツリーに対するものではない．
とりあえず，commit し「ワークツリー=リポジトリ状態」での作業と考えておけばよい．
1

2. またここでは merge と似た働きの rebase は説明しない．簡単に merge と rebase の違いを述べると，両方
ともブランチ A をブランチ B に統合するが (名前は適当)，merge は両方のブランチのコミット履歴を残すが
rebase はブランチ A(統合される側) のコミット履歴を改変する．
3.1 ブランチの作成・作業ブランチの変更
git branch [option]
[option]:なし:プロジェクトが持っているブランチ一覧を表示．
[option]:ブランチ名:新しいブランチを指定したブランチ名で作成．
[option]:-d ブランチ名:新しいブランチをしたブランチ名を削除．
git checkout [option] ブランチ名
[option]:なし:作業ブランチを指定されたブランチ名に変更．
[option]:-b ブランチ名:指定されたブランチ名で新しいブランチを作成し作業ブランチに変更．git
branch と git checkout を組み合わせ．
[option]:-b ブランチ名 <name or url>/ブランチ名:指定されたサーバ上の指定されたブランチ名に
変更．
3.2 ブランチの統合
git merge ブランチ名
現在のブランチにブランチ名で指定したブランチを統合する．現在のブランチが統合する側，指定した
ブランチが統合される側である．
3.2.1 統合時のコンフリクト (変更内容の衝突)
ブランチ A をブランチ B に統合したとき，A と B にある file.txt が統合できない状態となることがある (名
前はすべて例)．例えば，A は A で変更し続けていて B も B で変更し続けていて，単純に A の内容を B に統
合できない場合である．この時，以下のようなエラーメッセージが出て統合が一時的に止まる．
merge の conflict
Auto-merging file.txt
CONFLICT (content): Merge conflict in file.txt Automatic merge failed; fix conflicts and then
commit the result.
また merge に失敗した file.txt の中身も書き換えられ，コンフリクトが起きた場所に以下のようなメッセー
ジが追加される．
2

3. conflict が起きた場所に挿入されるメッセージ
HEAD
confict が起きている内容
=======
confict が起きている内容
統合される側のブランチ名
この場合，file.txt を自分で編集し，以下のようにすることでコンフリクトを解消・merge の完了を行う．
$ git add file.txt
$ git commit -m ”メッセージ”
3.3 サーバとのやりとり
git push name or url branch
name or url:サーバの名前:git push origin ..., git push git@gitlab.com:....
branch:アップロード先のブランチ名:アップロードするブランチ名:git push origin master:master, git
push origin branch-A:branch-A, git push origin branch-B
現在のブランチをアップロードする場合，アップロードするブランチ名は省略できる．よって git push
origin branch-B などとなる．
一人で開発をする場合，アップロードすることはあってもダウンロードすることはあまりない．ダウンロー
ドが必要になったら，プロジェクトのディレクトリを削除 (またはディレクトリ名.bk などに変更) し，git
clone で持ってくればよい．
特定のブランチの clone
git clone では，特に指定しない限り master ブランチしかダウンロードしてこない．よって他のブラン
チを clone するためには以下のどちらかの手続きが必要となる
• clone 時に指定
– git clone -b ブランチ名 name or url
∗ ブランチ名が分かっているなら直接ダウンロードする．
• clone して checkout
– git clone name or url
∗ 一旦，普通に clone する (master ブランチもってくる)，
– git branch -r
∗ git branch -r でサーバのブランチ一覧を表示・確認する．
– git checkout -b ブランチ名 name or url/ブランチ名
∗ checkout の時にサーバのブランチを指定してダウンロードする．ブランチ名が分からな
い場合などに有効である．
3

4. 4 基本運用
運用は，それぞれの使用環境で変わる．ここでは，倉重研究室の運用を基本として述べる．
4.1 ソースプログラムに対するブランチの作り方・名称
参考になるサイトとして Vincent Driessen の「A successful Git branching model」を紹介する．
• http://nvie.com/posts/a-successful-git-branching-model/
図 2 使用する Branch の種類
これを参考に，以下の三種類のブランチのみを使うこ
と．master ブランチはメインである．バージョンは 3 桁
のものを使用し，master ブランチに付与する．軽微な追
加・バグ取りなどは master ブランチ上で行って適宜バー
ジョンをつける．develop ブランチは開発用のブランチ
である．機能を追加しようとしたときに，時間がかかっ
たり動作テストの必要があったり動作テスト用のプログ
ラムを含んだりする場合に使うブランチである．追加す
る機能を表す名称をつけて develop-***(機能名称) とし，
完成後は master ブランチに merge する．hotfixes ブランチはバグ取り用のブランチである．バグの内容を表
す名称をつけて hotfixes-***(バグの内容) とする．バグ内容が一個なら hotfix-***かな．完成後は master ブ
ランチに merge する．以上，あくまで一人で開発する用である (Fig.2)．
master メイン，公開版，リリース版．バージョン等はタグで管理するのでメッセージには書かない事．
develop-*** 開発版．新しい機能の追加等．テスト後 master に merge．
hotfixes-*** バグフィクス用．軽微なものなら master 等を直接修正してもよいが，範囲が広くテスト
が必要な場合に使用．
4.2 それ以外
好きにするがよろし．
4