はじめに

• 最後には師範代に認定
• git覚えたらプロジェクトを heroku.com へ deploy しよう

心: git総論、心構え

• @iwamatsu
• 岩松さん
• DebianのOS開発
• 師範
• 彼がmergeやrebaseができなかった。別れたい

gitは分散

• リモートリポジトリとローカルリポジトリ
• 主な作業はローカルリポジトリで行う
  • 必要なデータがローカルにあるので動作が速い
• プッシュしてはじめて、他のユーザーと履歴共有する。
• ローカルリポジトリはおれのもの。リモートリポジトリはみんなのもの

リモートリポジトリとローカルリポジトリ

• HEAD いまチェックアウトしているもの
• 作業中に誰かがコミットをプッシュしても、ローカルは認識できない
  • リモートの作業を反映するまではその辺は気にしないで良い

gitは頑健

• 乱暴に言うとスナップショットシステム
• SHA1ハッシュで管理されている。
  • コミット、ツリー構造、実際のファイルのどれかが変更されるとハッシュ値が更新される

gitは時間的な変遷を管理する

• コミットの前はどうなっていたのか
• 前の状態に戻すことが出来る
  • git reflog
  • 消したbranchとかも参照を消しているだけなので、戻すことが出来る
  • 90日まで
  • git gcするまで
  • git config --global gc.auto 0 でgcを無効にできる
• 常にコミットしておいた方がむしろ安心。

質問

• svnから移行するときの説得方法は？
  • コミット権限とりあげよう
• githubが重い
  • enterprise速いよ
• git gc実行こわい。どれくらいのサイズですればいいの。
  • 大きいのは仕方ないのでは
  • git objectを集めるのが趣味なので気にしない人もいる
  • 検索かけたときに遅くなったら、とか目安になるかも。

技:

• 小川さん
• @@conceal_rs
• jpmobileの人
• 師範

本日の課題

• 3〜5人のチームで
  • コミットメッセージちゃんとかく
  • git pull --rebaseを怖がらずにやる
  • git pull との違いを実感する

コミットメッセージをしっかり書く

• 当たり前のことだが、あまり実践されていない
• コミットメッセージのみを介して会話する
• 意思疎通が出来るレベルでメッセージを書くことが目的

git pull -rebaseを怖がらずに

• 今日はコンフリクトが起こりやすい題材となっている

git pull との違いを実感する

• mergeとrebaseの違いを実感する
• mergeだとコミット家系図が入り込んでしまうため、コミット間の相関関係が分かりづらい

題材

• Numbersファイルをチームで編集
• チーム間ではコミット内容に関する相談、会話をあまりしない
• pushのタイミングは告知しないでいいよ
• commitしてpushすることを5回ほど繰り返す

Numbersとは

• 1〜10の数値が書かれた10行のファイル
• 好きな数値の後ろに記号を追加/削除する
• コンフリクトしやすくしよう！
• コミットメッセージに、追加した記号や数値に関する情報を記載する
• コミット内容に関しては、このコミットメッセージでやりとりする
• コミット内容に関しては、相談・会話をしない！
• コミットメッセージは、コミットオブジェクトの要約であることを意識する
• 自分のコミットが連続しているのは敗北！
• git pushの声掛けはok

最後にやったことの確認

• githubのNetworkを確認
• git log --graph --pretty=oneline --decorate

repository

http://github.com/git-dojo/teamNN をcloneして始める

実技

Numbersを自由に更新

実技2

pull時に必ずrebaseでやる縛り

git commit -> git push | git pull --rebase

git remote update -> git rebase origin/master

テクニックの解説

• rebaseはコミットをかぶせる感じ
• mergeはコミットを統合する

git pushが失敗するのは？

• remoteに新しいコミットがあると失敗する

このときgit pull

• remoteにある、差分をmerge
• localのコミットをmerrge

git pull --rebase

• remoteの差分を先にrebase
• localのコミットをmergeする

git pull --reaseでconflict

• 無名branchがチェックアウトされた状態
• どうする

1. ファイル編集
2. git add Numbers
3. git rebase --continue

• つまりgit commitしないこと

git rebaseの利点

• 見やすい
• 誰がcommitしたか分かりやすい

git merge

• conflictしない
• 自分の元々の編集履歴が残るので、後になって調べやすい
• commitに問題があったかどうかなどの調査しやすい

merge か rebase か

• 状況次第であることを意識する
• 基本的にはrebaseしてからpushが良い
  • 他人がcommitしていることが意識出来る
• ブランチはmergeが良い

無名ブランチ

commitしないこと

• git rebase --continueで続ける
• git rebase --abort
• git rebase --skipでそのコミット捨てちゃう

今日覚えた事のメモ

git push するたたびにgithubのアカウントとpw聞かれるのはなぜ？

以下のように、.git/config内の記述がhttps〜になっていると聞かれる

   url = https://github.com/git-dojo/team10.git 

ので、このように変更する。

    url = git@github.com:git-dojo/team10.git

githubのNetworkみたいなものをコマンドラインで見る

git log --graph --pretty=oneline --decorate

git pullする際のお作法

--rebaseをデフォルトで付ける。

git config branch.master.rebase true

diff

git diff --word-diff

作業の流れ

1. いろいろ作業
2. git add
3. git commit
4. git pull --rebase
5. conflictを解決
6. git add
7. git rebase --continue

githubのNetworkの遷移

git pull --rebaseを知らない頃

git pull --rebaseを覚えた後

blog

http://ppworks.hatenablog.jp/entry/2012/04/22/175349に転載しました。