Gitについてまとめメモ Git
Gitを仕事で使いそうなのでちょっと勉強
参考URL
http://qiita.com/YusukeHosonuma/items/14c59f3878d640a401a1
http://www.slideshare.net/kotas/git-15276118
http://www.slideshare.net/matsukaz/git-17499005?related=1
------------------------------------------------
http://www.slideshare.net/matsukaz/git-17499005?related=1
subversionとgitでは commit のやる内容が違う
■subversionの場合
<img src= http://img-cdn.jg.jugem.jp/3eb/1172978/20151229_705928.png alt= width= 400 height= 321 class= pict />
subversion
commit：リポジトリ（共有サーバー上の）
update：ローカル更新
■gitの場合
<img src= http://img-cdn.jg.jugem.jp/3eb/1172978/20151229_705929.png alt= width= 400 height= 300 class= pict />
git
commit：ローカルリポジトリ反映
push ：ローカルから、リモートリポジトリへ反映
fetch ：リモートリポジトリから、更新を取得
merge/rebase：リモートリポジトリの更新をローカルに反映させる
gitではほとんどの操作が、ローカルで完結する
（push fetch以外）
■データ領域
gitで大事なデータ領域は３つ
・ワークツリー（作業ディレクトリ）
・ステージングエリア（インデックス）
・Gitリポジトリ
<img src= http://img-cdn.jg.jugem.jp/3eb/1172978/20151229_705930.png alt= width= 400 height= 321 class= pict />
<img src= http://img-cdn.jg.jugem.jp/3eb/1172978/20151229_705931.png alt= width= 400 height= 321 class= pict />
<img src= http://img-cdn.jg.jugem.jp/3eb/1172978/20151229_705932.png alt= width= 400 height= 321 class= pict />
git init git管理を開始する
<img src= http://img-cdn.jg.jugem.jp/3eb/1172978/20151229_705933.png alt= width= 400 height= 321 class= pict />
git add <filepattern>
リポジトリに追加したい対象を指定する
ファイルを修正した場合も git add
git add . 「.」はすべての未登録ファイルがステージされる
<img src= http://img-cdn.jg.jugem.jp/3eb/1172978/20151229_705934.png alt= width= 400 height= 321 class= pict />
git commit -m <msg>
更新内容をリポジトリに登録する
<img src= http://img-cdn.jg.jugem.jp/3eb/1172978/20151229_705935.png alt= width= 400 height= 321 class= pict />
git rm <file>
ファイルを削除する
git rm dir1/dir2
<img src= http://img-cdn.jg.jugem.jp/3eb/1172978/20151229_705936.png alt= width= 400 height= 321 class= pict />
<img src= http://img-cdn.jg.jugem.jp/3eb/1172978/20151229_705937.png alt= width= 400 height= 321 class= pict />
rmでファイル削除後はその内容を反映（コミット）させる
git mv ：ファイルやディレクトリを移動する
git status ：ワークツリーの状態をみる
git log ：コミットログをみる
ブランチとはメインと、別の流れで作業を続ける機能
git merge <branch>：現在のブランチに指定ブランチをマージする
git clone <url>：リモートリポジトリを ローカルに複製
git clone git@github.com:a/b.gif
<img src= http://img-cdn.jg.jugem.jp/3eb/1172978/20151229_705938.png alt= width= 400 height= 321 class= pict />
------------------------------------------------------------
------------------------------------------------------------
------------------------------------------------------------
http://www.slideshare.net/kotas/git-15276118
% git checkout -b foo master（= git checkout -b foo 4714e3cf1826） ブランチ名の代わりにリビジョンを指定も可能
% git show master （= git show 4714e3cf1826）
% git branch topic master （master から topicをつくる） ブランチをつくることは、こみっとのさらなる別名をつくるのと同じ
★マージ
gitのマージには２種類ある（Fast-Forward 早送り：元が変更されてないなら使えそう／ Non Fast-Forward 早送りではないマージ：元が変更されてた後なら、使えそう）
---------------------
git merge topic 歯や送りできればする、無理なら普通のマージ
git merge --no-ff topic 常に普通のマージ
git merge --ff-only topix 常に早送りする（できなければエラーとする）
---------------------
Fast-Forwardの弊害１ ブランチをマージしたという事実がれきし（コミットグラフ）に残らない
git revert <commit>
<commit>（リビジョン）のコミットを取りけすためのコミットをつくる
git reset --hard <commIt>
<commit>（リビジョン）時点の状態まで完全にまきもどす
Fast-Forwardの弊害２
ブランチのマージを取りけしづらい
■まとめ ２種類のマージ
---------------------------------
Fast-Forward ： 早送り
・コミットグラフとしてけっかが同じなら、同じコミットまで進めてしまうこと
・「マージした」という記録が残らない
・マージを取りけしづらい
Non Fast-Forward 普通のマージ
・gitが頑張って計算するマージ
---------------------------------
★rebase
git rebase master
masterから取得し、その上にこれまでの変更点を反映させる
rebaseで創られたコミットは、元のコミットとほぼ同じ内容だが別のコミットになる
（中にある１つ前の内容が違うので、正しくは別のコミットは別物）
★git push origin topic
topic を origin（サーバー）に同期
localにあるコミットされてる内容をサーバーにアップする
pushされているブランチを rebaseすると pushできなくなる
よって共有のブランチでは、rebaseしてはいけない。
絶対NGなの。push -f
push -f で強制で上書きpush可能だが、他の人がpullする時にマージする必要があったり
コミットログがおかしなことになるのでしてはあかん
mergeだとコミットがいくつあろうとコンフリクト解消は一度だけ
したがって rebaseより mergeの方が楽
リベースの功罪
□よい点
・コミットグラフがきれいになる
→マージ後のログがきれいにあるので、masterにマージする直前にするのはOkとすることがある
・githubなどのオープンソースプロジェクトにプルリクエストを送る場合は
rebaseしてから送るのがマナー
□悪い点
・pushされたブランチをリベースすると push不可能になる
・マージしたという事実が失われる
・マージと比較すると、コンフリクト解消が面倒
------------------------------------