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.4 -みんなで Git-
倉重健太郎
2015 年 2 月 8 日
1 前提
本資料は，万人向けの資料ではなく，以下の使用状況下を想定した資料である．
• Git サーバとして GitLab を用いる．特に，以下のどちらか (もしくは両方) を想定している．
– 研究室に自前の GitLab サーバを構築している．
– GitLab.com にアカウントを持っている．
2 概要
GitLab を介した多人数での開発や情報共有について述べる．まず GitLab におけるプロジェクトのアクセ
ス種別について述べ，次にプロジェクトにおけるメンバー種別，グループの使い方について述べる．
2.1 プロジェクトのアクセス種別
プロジェクトのアクセス種別は以下のようになる．
Private このプロジェクトに明示的に登録されたユーザしかアクセスできない
Internal GitLab に登録されたユーザなら clone できる
Public プロジェクトの url(特に https) を知っているものなら誰でも clone できる
2.2 プロジェクトにおけるメンバー種別
プロジェクトが Internal 以上であればメンバー登録されなくても clone はできる．しかしそれ以上のこと
をしようとしたり，Private のプロジェクトなら clone するためにもメンバー登録されないければいけない．
登録されるメンバーの種別は以下のようなものがある．
• Guest
• Reporter
• Developer
• Master
1

2. • Owner
詳しくは GitLab の help の User documentation-Public access を参照のこと．特に使用するものについて
簡単に説明する．
Reporter Private プロジェクトに対して clone が出来る
Developer branch を切ったり push 出来る
Owner プロジェクト作成者と同等の権限がある
2.3 グループについて
作成したプロジェクトに登録する人間が基本的に決まっていて，しかも人数が多いとメンバー登録が面倒で
ある．そのような場合，グループを使うと手間が減る．複数人数のメンバーをグループに登録しておくと，プ
ロジェクト作成時に Namespace としてグループを選べてプロジェクトのメンバーとして初期登録できる．も
しくはグループからプロジェクト作成が選べる．
2.4 多人数開発の方法
プロジェクトのアクセス種別およびメンバーのアクセス種別によって方法は異なる．大きく分けると以下の
ようになる．
Fork-Merge request
GitLab の該当プロジェクトのページから Fork を選び，自分のところにプロジェクトのコピーを作成す
る．以後，自分のプロジェクトとして編集を行い，適度なところで元のプロジェクトに Merge request
を送る．元のプロジェクト管理者用は Merge request を受け取ったら差分を確認しながら merge して
いいか考える．
該当プロジェクトにアクセスできるならこの方法となる．
直接編集
GitLab の該当プロジェクトを直接編集する．branch も作成できるし push も出来る．
該当プロジェクトの Developer 以上であれば可能である．
3 基本操作
3.1 Fork の方法
GitLab の該当プロジェクトの左ペインに Project があり，そのページ内右上に Fork という文字がある．
それをクリックすると Fork できる．
3.2 直接編集
git clone して編集，普通に push する．
2

3. 3.2.1 安全な直接編集
自分の名前等でブランチを作成して，その中で編集する．本筋のブランチとの merge は自分で行わず，ブ
ランチ管理者 (作成者) に連絡する．ブランチの作成の仕方は，普通に git branch でも良いが，GitLab の該
当プロジェクトの左ペインに Commits があり，そのページ内に Branches がある．そこに New branch があ
り，そこでも作成できる．
3.2.2 push 時のコンフリクト
多人数開発では，特にコンフリクトが懸念される．自分のワークツリーとリポジトリはコンフリクトが起き
ておらず同一のものとしても (そのコンフリクトは Git Lev.3 で解消すること)，自分のリポジトリとサーバの
リポジトリのコンフリクトが生じる可能性がある．このコンフリクトが起きた場合，以下のコマンドによって
解消を試みる．
• pull
• fetch して merge/rebase
pull = fetch して merge/rebase だが，変なことになった時のわけわからんさは pull > fetch して
merge/rebase である．本当は fetch して merge/rebase の手順に慣れた方がよい．
git pull
.git/config で指定されているサーバのリポジトリをダウンロードし merge する．
4 基本運用
運用は，それぞれの使用環境で変わる．ここでは，倉重研究室の運用を基本として述べる．
4.1 プロジェクトのアクセス種別
GitLab.com を使用する場合，プロジェクトのアクセス種別は Private が基本である．研究室内 GitLab を
使用する場合，プロジェクトのアクセス種別は Internal が基本である．
4.2 Fork と直接編集どちらを使うか
Fork および直接編集 (直接編集ではブランチ名に自分の名前を入れるかどうか)，は運用による．Git-
Lab.com を使用する場合は Fork が基本，研究室内 GitLab を使用する場合は直接編集が基本となる．方針は
以下の通り．
Fork 他のプロジェクトをベースに自分用のものを作成したい or 作成者と使用者に分かれている or 顔を合
わせられる距離におらず直ぐにディスカッション等できない
直接編集 (リーダーなし) 一つのものを多人数で開発 or メンバー全員が信頼でき且つ顔を合わせられる距離
にいる
3

4. 直接編集 (リーダーあり) Fork と直接編集 (リーダーなし) の中間で，一人の人に master の管理を任せた方
がよさそうな場合である．プロジェクト作成者が希望する場合など．
直接編集 (リーダーなし) と直接編集 (リーダーあり) のどちらにおいても，ブランチに内容と自分の名前を
入れて以下のようにする．二つの違いは，master に各ブランチを merge してタグ付けするのが全員なのか
(リーダーなし)，一人なのか (リーダーあり) である．
例
master
developer-e greedy-kurashige
hotfixes-issue1234-clione
ここで GitLab には issue という機能があり，これからやりたいことや現在分かっている問題などを共有す
ることができる．追加や確認などは web ブラウザ経由で可能であり，自動的に#番号が割り当てられる．こ
の番号を使って issue1234(issue #1234) とするのが最も理想的である．ちなみに，commit 時のメッセージ
に”fixing #1234”(複数の場合は fixing #1234, #1235 and #1236 のようにカンマや and で区切る) と入れ
ると自動的に当該 issue を close(終わったことに) してくれる．
4