## page was renamed from git
#acl alstamber:read,write,revert,delete,admin All:read

== なにこれ ==
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の設定を忘れない。