git道場#1参加した #gitdojo

はじめに

  • 最後には師範代に認定
  • 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を集めるのが趣味なので気にしない人もいる
    • 検索かけたときに遅くなったら、とか目安になるかも。

技:

本日の課題

  • 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を知らない頃

f:id:naoto5959:20120422172634p:plain

git pull --rebaseを覚えた後

f:id:naoto5959:20120422172636p:plain