Edited at

git道場#1のメモです。(2012.4.22) #gitdojo

More than 5 years have passed since last update.


はじめに


  • 最後には師範代に認定

  • 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


blog

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