ログイン
編集不可のページディスカッション情報添付ファイル
"alstamber/git"の差分

MMA
5と6のリビジョン間の差分
2012-09-04 23:42:54時点のリビジョン5
サイズ: 9665
編集者: alstamber
コメント:
2012-09-05 00:06:10時点のリビジョン6
サイズ: 11757
編集者: alstamber
コメント:
削除された箇所はこのように表示されます。 追加された箇所はこのように表示されます。
行 121: 行 121:
  * つまり<source_branch>は<source_branch>:<target_branch>(source_branchとtarget_branchは同じ名前)と書いたのと同じ。
行 127: 行 128:
 * <repository>の<source_branch>をとってきて自分のlocal repositoryの<target_branch>にmergeする。  * <repository>の<source_branch>を自分のlocal repositoryの<target_branch>にとってきたあと、今いるbranchにmergeする。
 * pushの真逆の操作ではないことに注意。
行 131: 行 133:
 * 例えばoriginのmasterをpullしたい時は
{{{
git pull origin master:master
}}}
 * pushと同じように略記が可能。
 * originのmasterをpullしたい時は
行 139: 行 137:
 * <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が使用される)。

なにこれ

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。

  • 現在使用している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

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>

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

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

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

other

garbage correction

git gc

alstamber/git (最終更新日時 2012-09-07 22:43:21 更新者 alstamber)