git-dojo参加ブログ
ちょっと遅くなったけどgit-dojoの参加ブログです。
前半は@iwamatsuによるgitの説明で、後半は複数名でチームを組んでgitの使い方を学びました。特に「rebaseは怖くない！」ということを学べる構成になっていました。以下で講演の内容とやったことをまとめていきます。
講演内容まとめ
gitは分散バージョン管理システムである。
リモートリポジトリと複数のローカルリポジトリから構成されていて、チェックアウト、コミットは手元にあるローカルリポジトリで行う。
そして、他のサーバーに存在するリモートリポジトリにプッシュする。
履歴の参照や差分の確認、コミット、マージ、などを行うとき、ローカルで作業でき、リモートにアクセスしなくても作業できるので、動作が早い。
プッシュして初めて履歴などを共有することができる。
過去のコミットの履歴を全てハッシュで持っていて、時間的な変遷を管理することができる。
そしてgit reflogで作業履歴を確認することができる。
git-reflogを使えば、自分がこれまでHEADとして参照してきたコミット、つまり自分の過去の操作を一覧できる。これを利用して操作ミス直前の時点（コミット）を特定できれば、git-resetでその時点に――それがたとえgit-logに出てこない時点であっても――戻ることができる。つまり、この二つを覚えておけば大抵の操作ミスから回復できる。
90日以内なら取り戻すことができる。
git config --global gc.auto 0 # で90日たっても消えないようになる。
検索が遅いと感じたらgcする。
題材
Numbersファイルをチームで編集。
同じ人が連続でpushしないように順番を決める。
コミット、リモートにあげることを全員が５回以上する。
ルール
コミットごとに、自分で選んだ適当な数値の後ろに記号を追加削除する。
コミットメッセージに追加した記号や数値に関する情報を記載。
題材２
基本は題材１と同じ。追加事項はpullするときに--rebaseを必ずすることだけ。
.git/confug 以下にrebase = trueを書くことで必ずrebaseになる。
または、git config branch.master.rebase trueで勝手にgit pull --rebaseになる。
rebaseすることによる違い
rebaseすることでmergeのポイントをずらすことができる。
rebaseしなければクローンした時点、rebaseすれば最新のところにmergeすることになる。
以下で図を使って簡単に説明。
- 状況
originと並行に作業しているとします。
- rebaseなし
コンフリクトを解消してマージします。
すると、a,b,cの作業情報は残るがこれが続くとネットワーク図が複雑になっていきます
- rebaseあり
一番最新のところにコンフリクトを解消したa',b',c'がマージされます。a,b,cの情報はa',b',c'に変わってしまうがネットワーク図が見やすくなります。(履歴として残るコミットの数がrebaseなしより一回少ない)
手順
git clone git@github.com:git-dojo/team10.git
# 編集して
git add Numers
git commit -m 'コミットメッセージ' # コミットメッセージを書いてコミット。
git push origin master #でコンフリクトが起きたら
#最新バージョンをローカルに入れる
git pull --rebase origin master
#コンフリクトを解消してもう一度
git add Numbers
git rebase --continue
git push origin master
題材１のように普通にマージしたときにコンフリクトを起こすとmasterに戻るが、
git pull --rebaseでコンフリクトが起こると無名ブランチにはじかれる。
そこで、コンフリクトを解消してaddしたあとにgit rebaseをしてmasterに戻る必要がありcommitしてはいけない。commitがいらないのでコンフリクト前のコメントが反映される。
間違えて、無名branchにコミットしてしまった場合は以下のようして戻る。
git checkout -b hoge # 新たにブランチを切って移動。
git checkout master # masterに戻って
git merge hoge # 作成したブランチをマージする。
もしくは以下のいずれかのコマンドを打つ
git rebase --skip
git rebase --abort
小ネタ
- git config --global color.ui auto # 文字がカラーになる
- tig # を打つとコミット履歴が見れる。tigをインストールする必要がある
- git_box, towerっていうGUIもある
- git pull --rebase #（二回目以降はorigin masterを省略できる）
- git pullしてmergeコミットが入った場合の戻し方
git reset --hard ORIG_HEAD #でmergeされる前の状態に戻せる
最後に
mergeとrebaseの違いを学びました。今回使用した以下のリポジトリのネットワーク図を見るとわかりますが、前半はrebaseしていなかったのでネットワーク図がぐちゃぐちゃです。しかし、後半はrebaseをしていたのでまっすぐで綺麗なネットワーク図になっています。
今回使用したリポジトリ
http:github.com/git-dojo/team10
このようにrebaseをするとネットワーク図がわかりやすくなるが、上で説明したように情報が失われてしまいまいます。どちらが優れているかという質問に対して、「どちらも一長一短であるが私は必ずrebaseしています」という回答でしたので、とりあえず私もrebaseすることにします。
今回はブランチを切って作業をしなかったので次回はブランチを切った場合について詳しく学びたいです。
