なにこれ

gitを運用する上での知識の整理。

local repositoryとremote repository

• gitは分散バージョン管理システム。
• 分散バージョン管理システムではファイルの変更履歴を保持しているrepositoryが各開発者の手許に一つある。
• 開発者は普段の開発ではプログラムを書いてそれを手許のrepository(local repository)に反映するという作業をやる。
  • この反映する作業をcommitという。
• commitが溜まってきたら、それを各開発者で共有しているrepositoryにアップロードする。
  • 会社の場合だと会社の共有サーバなんかにおいてあるrepository。たいていremoteにあるのでremote repositoryという。
  • この作業をpushという。
• 開発者はremote repositoryを見に行ってその内容を自分のlocal repositoryに統合するという作業をやる。
  • こうすることで自分のlocal repositoryに常に他の開発者の成果が反映されるようになる。
  • この作業をpullという。
• local repositoryは一から作る場合と、元からあるremote repositoryをパチってきて作る場合がある。
  • 後者をcloneという。

working directoryとindexとrepository

• local repositoryは3段構えになっている。
• 実際にファイルを置いといて弄るworking directory
• ファイルの変更履歴を保持しているrepository
• その仲立ちをするindex
• commitするときは、まずindexにcommitしたいファイルを登録(addという)する。それからcommitする。

initial settings

git config --global user.name "<username>"
git config --global user.email "<mail address>"

create

create new repository

git init

create new public repository

• 慣例としてディレクトリ名に.gitをつける。
• --bareをつけると、bare repositoryになる。bare repositoryは管理情報のみを持つ。
  • commitなどができない。

git --bare init

clone

clone local repository

• 既存のlocal repositoryを複製する。

git clone /path/to/repository

clone remote repository

• 既存のremote repositoryを複製する。

git clone username@host:/path/to/repository

check

check status

• working directoryとindexの状態を確認する。

git status

check differences of file

git diff <filename>

check repository log

• repositoryの変更履歴を確認する。

git log

add/remove

add files

• indexにaddする。

git add <filename>

• すべてをaddする。

git add *

remove files

• indexからremoveする。

git rm <filename>

commit

commit

git commit -m <message>

commit all file edited

• git addする必要なし。

git commit -a

push/pull

add remote repository

• push/pullするためにremote repositoryを予め登録しておく。

git remote add <name> <url>

• 通例次のように使う。
  • push/pullでrepository名を省略するとoriginという名前につなぎに行こうとするので。

git remote add origin <remote repository url>

push

• <repository>の<target_branch>にlocal repositoryの<source_branch>をpushする。

• <target_branch>を省略すると、<source_branch>と同じ所にpushされる。

  • つまり<source_branch>は<source_branch>:<target_branch>(source_branchとtarget_branchは同じ名前)と書いたのと同じ。

• cloneして生成したrepositoryではgit pushだけでgit push origin masterと同じ事になる。

git push <repository> <source_branch>:<target_branch>

pull

• <repository>の<source_branch>を自分のlocal repositoryの<target_branch>にとってきたあと、今いるbranchにmergeする。

• pushの真逆の操作ではないことに注意。

git pull <repository> <source_branch>:<target_branch>

• originのmasterをpullしたい時は

git pull origin master

• <target_branch>が略記されたときは、<source_branch>:と表記したことになる。

  • <source_branch>:という表記は、<source_branch>を今いるbranchにmergeだけして<source_branch>をこっちには保存しないという意味になる。

• すなわち上の表記はoriginのmasterを持ってきて、こっち側の今いるbranchにmergeするという意味になる。
• 上の規則により下の表記の意味は違うということになる。

git pull origin hoge:hoge
git pull origin hoge

• 最初の表記だと、こちら側のrepositoryにhogeというbranchが作成されるが、その次の表記だとhogeというbranchは作られない。
• どちらの表記でも今いるbranchにmergeはされる。

tracking branch

• remoteにあるbranchの状態をlocalに持っておくためだけのbranch。
• 以下のコマンドを実行した時の挙動を考える。

git pull

• まず<repository>が省略されているが、この場合originであると解釈される。

• <source_branch>が省略されているので、次のような表現にreplaceされる。

refs/heads/*:refs/remotes/origin/*

• <source_branch>の部分にあるrefs/heads/*はremoteにある全てのbranchを示す。

• <target_branch>の部分にあるrefs/remotes/origin/*がtracking branchを示す。

• つまり次のように展開される。

git pull origin refs/heads/*:refs/remotes/origin/*

• pullはfetchとmergeを順に行うコマンドであるので、次にfetchとmergeへの展開が行われる。

git fetch origin refs/heads/*:refs/remotes/origin/*
git merge origin/master

• fetchコマンドでoriginのbranchすべてをlocalのtracking branchにもってくる。
• mergeコマンドで現在いるbranchにoriginのmaster branchがmergeされる(この時にtracking branchが使用される)。

branch

• 最初はmasterというbranchが作られる。

masterとtopic branch

• masterからtopic branchを作成。
• topic branchでの変更が終わったら、masterへmerge。

head

• 現在使用しているbranchの先頭。
  • デフォではmasterの先頭。

stash

• branchに対して何らかの変更を行った状態でbranchを切り替えると、その変更は切替先のbranchに引き継がれる。
• 同じファイルが切替先のbranchで既に変更されているとconflictしてしまう。
• 切替元branchにcommitしてから切り替えるか、一時的にstashと呼ばれる領域に変更を退避する。

merge

• branchを統合する事を考える。
• branch Aからbranch Bが分岐し、branch Bに変更を行った後branch Aとbranch Bをmergeすることを考える。
• branch Aに何の変更も行われていなければ、branch Aの先頭をhead(=branch Bの先頭)にするだけでmerge完了。
  • fast-forward mergeという。
• branch Aに変更が行われている場合は、両方の変更を取り込んだ新しいcommitを作成する。
  • headは新しいcommitに移動する。

rebase

• branch Aからbranch Bが分岐し、branch Bに変更を行った状態を考える。
• この状態でrebaseするとbranch Aの後ろにbranch Bの変更が付け足される。
• branch Aはそのままなので、branch Aの先頭をheadに移動するにはmergeを行えば良い。

A successful git branching model

• in Japanese : http://keijinsonyaban.blogspot.jp/2010/10/successful-git-branching-model.html

• in English : http://nvie.com/posts/a-successful-git-branching-model/

create branch

git branch <branchname>

list branch

git branch

checkout branch

• branchの切替

git checkout <branch>

create branch and checkout branch

• branchつくって切替を同時にやる。

git checkout -b <branchname>

merge branch

• <commit>という名前のbranchがheadの指しているbranchにmergeされる。

git merge <commit>

delete branch

git branch -d <branchname>

correct conflict

• conflictによってmergeに失敗した時はどうするか。
• conflict箇所を修正してからcommitすればよい。

rebase branch

• <branch>にたいしてrebase。

git rebase <branch>

• conflictによって失敗した場合は該当箇所を修正し、

git rebase --continue

show differences between two branches

git diff <source_branch> <target_branch>

pullとmerge

• pullはremoteから内容をとってきて、mergeするという作業をしているだけ。
• 内容を取ってくるためのコマンドとしてfetchというものがあるので、内部的にはfetch→mergeしてるだけ。
• pullの際のmergeの挙動とは？

local repositoryのbranchに何も変更を加えていない時

• fast-forward mergeされるだけ。

local repositoryのbranchに変更をくわえている場合

• 頑張ってmergeする。conflictする場合は知らせてくれるので、修正してcommit。

fetch

• 前項で触れたが、remoteから内容を取ってくるだけのコマンドとしてfetchが存在する。
• fetchでとってきた内容はFETCH_HEADという名前でcheckoutして参照可能。

tag

• commitに名前をつける。

軽量タグと注釈付きタグ

• 軽量タグは名前だけ付けられる。
• 注釈付きタグは名前とコメント、署名を付けられる。
• 軽量タグは使い捨て、注釈付きタグはリリースの際につけるフォーマルなもの。

add lightweight tag

• headにlightweight tagをつける。

git tag <tagname>

• 任意のcommitにtagをつけることが可能。

git tag <tagname> <commitID>

• commitIDはgit logで調べる。

add annotated tag

• headにannotated tagをつける。

git tag -a <tagname>

• commentをつける時は-mオプション。

list tag

git tag

delete tag

git tag -d <tagname>

correct commit

revert

• 直前のcommitを帳消しにするcommitを新たに作る。

reset

• commitを消す。
• modeが3つある。
  • softではheadの位置だけを戻す。
  • mixedでは加えてindexも戻す。
  • hardではworking directoryも戻す。

reset commit

• 一つ前のcommitをsoftモードで消す。
  • HEAD^はHEADの一つ前という意味。

git reset --soft HEAD^

• 消したcommitはORIG_HEADという名前で参照可能だから

git diff ORIG_HEAD

とすれば差分を閲覧できる。

• ORIG_HEADはresetのみならずmergeのような大きな変更を伴うコマンドの際には必ず作られる。
  • 前のHEADの状態を保持してる。

edit commit

commit --amend

• 直前のcommitを編集する。

cherry-pick

• 別のbranchから指定したcommitを現在のbranchに取り込む。

rebase -i

• 過去のcommitの入れ替え、統合、削除、書き換え。

squash

• mergeのオプション。
• あるbranchのcommitすべてをまとめてひとつのcommitにして現在のbranchにmerge

amendを使う

git commit(あっ間違えた！)
(間違いを修正)
git commit --amend

HEADの状態にworking directoryにあるファイルを戻す

git checkout -- <filename>

commitの編集方法使い分け

あれこれゴミコードを書いてみたけどもう要らない

• 例えばゴミコードをn回commitしたのなら

git reset --hard HEAD~{n}

topic branchをmergeしたけど実はまだ不完全だった。mergeをやり直したい。

• mergeのような危険な操作ではORIG_HEADが作られるので、そこに向けてresetをかければよい。

git reset --hard ORIG_HEAD

pushしたあとに自分のやったcommitにバグがあることが判明。元に戻したい

• 既にpushしちゃってるのでresetなんてやると大混乱のもとになる。
  • commit log大崩壊！
• revertをつかえばよい。

other

garbage correction

git gc

installation gitlab

• 基本的にはhttps://github.com/gitlabhq/gitlabhq/blob/stable/doc/installation.mdに書いてあるとおりにやれば良い。
• nginxの設定は、外部からもアクセスできるようにlisten portを80番にしておく。
• DNSの設定を忘れない。