git-pullで私なりの解釈で aha！が来たのでメモします。
これからは git-pull --rebaseにしよー
下記をそのままという感じなのですがｗ
http://www8.atwiki.jp/git_jp/pub/Documentation.ja/user-manual.html#using-git-rebase

そういえばトッポさんが言ってた：git-pull --rebaseを使うといいよ

git-pullよりgit-pull --rebaseを使うといいよ(ただしという注意(下記太字)があるのでその辺は注意。ほとんどの人は関係ないと思うんだけど。。。)

Here's a tip for keeping up to date: In lieu of using git pull to download the latest changes, use git pull --rebase. Instead of cluttering the history with a merge commit, it reapplies your changes to the latest upstream. The only caveat is that you shouldn't use this method if you've already published the changes to another repository. Doing so would cause problems for anyone who has already downloaded the original commits.
http://www.tpope.net/rails-git-best-practices

でgit-pullとgit-pull --rebaseの違いをgit-rebaseの説明を読んで理解する

状況

o--o--O--o--o--o <-- origin
         \
         a--b--c <-- mywork

"mywork"は"origin" から単純に並行に行なわれています
プロジェクトの上流では他の興味深い変更が行なわれ、 "origin" は発展します

で、(上の状況から)git-pullした場合

o--o--O--o--o--o <-- origin
         \          \
         a--b--c--m <-- mywork

"pull" を使用して変更をマージさせることができます；結果として新しいマージコミットが生成されます

で、(上の状況から)git-pull --rebaseした場合

originが最新であればgit rebase originでいいと思うのだけど、(originが)最新でない場合はgit-pull --rebaseすればいいのだと解釈しました。

o--o--O--o--o--o <-- origin
                      \
                      a'--b'--c' <-- mywork

これは、mywork からあなたの各コミットを削除し、一時的に (".dotest" という名前のディレクトリ内に)パッチとして保存し、 mywork を origin の最新バージョンの位置に更新し、その後で保存した各パッチを新しい mywork ブランチに適用します。

コンフリクトがある場合は、下記にあるように修正してaddしてgit rebase --continueすればok。

各git-somethingでのコンフリクト時のリカバリ

• git merge 時のリカバリ
  o 手動マージ -> 動作確認 -> add -> commit

• git rebase 時のリカバリ
  o 手動マージ -> add -> git rebase --continue

• git pull 時のリカバリ
  o メンテナの場合 -> 一蹴
  o ユーザの場合 -> 手動マージ -> add -> commit

• git-am 時のリカバリ ( apply mail = メールで送られるパッチの適用 )
  o メンテナの場合 -> 一蹴
  o ユーザの場合 -> 手動マージ -> add -> git-am --resolved

http://d.hatena.ne.jp/conceal-rs/20080928/1222612534

Refs

http://www8.atwiki.jp/git_jp/pub/Documentation.ja/user-manual.html#using-git-rebase
http://www.tpope.net/rails-git-best-practices
http://blog.s21g.com/articles/535:tpope.netさんのRails with Gitのためのベストプラクティス http://d.hatena.ne.jp/conceal-rs/20080928/1222612534：gitでの開発の流れがわかってかなり++

自分用メモ。
screenでは複数windowを開いていますが、最近なんとなく開く数が決まってきたので、最初から開いておくようにしました。瀧内さんは以前8つ開いてるって言ってたので(!)、私の6つなんか かわいいものなハズ。

windowの役割

現在のメインプロジェクトはブログなので、それをベースに以下の5つを開いています。

• 0 emacs, エディタ
• 1 shell
• 2 tail -f log/development.log
• 3 script/console
• 4 同時進行のプロジェクト： folked prawn.git
• 5 railsのdir ソースを読むのに使う

2008.10.03の.screenrc

他の人よりはショボショボなのですが、ご愛敬ということで。 emacsclientを使っているので、emacsはフルパスで書いています。

   1  escape ^tt
   2  
   3  hardstatus alwayslastline "[%02c] %`%-w%{=b bw}%n %t%{-}%+w"
   4  scrollback 4000
   5  vbell off
   6  #idle 1200
   7  #blankerprg /usr/local/bin/tss
   8  
   9  chdir "/home/hibi/blog.git" #メインのprojectに移動
  10  
  11  #screen -t emacs 0 /usr/bin/emacs #emacs 21.4
  12  screen -t emacs 0 /usr/local/bin/emacs
  13  screen -t bash 1
  14  stuff "ruby ./script/server -d" #開いたwindowにこのコマンドだけ入力しとく、実行してもいいのですが実行したくない時も多いので
  15  
  16  screen -t tail 2 tail -f log/development.log
  17  
  18  screen -t console 3 ruby ./script/console
  19  
  20  chdir "/home/hibi/my.prawn.git"
  21  screen -t prawn 4 #前の行でcdしてからwindowを開く
  22  
  23  chdir "/home/hibi/test/vendor/rails/actionpack/lib/action_controller"
  24  screen -t rails 5
  25  
  26  chdir "/home/hibi/blog.git" #以後開くすべてのwindowをblog.gitにするため
  27  select 1 #window1を選択

Refs

http://www.limy.org/program/screen_command.html：日本語リファレンス
http://www.pervasivecode.com/blog/2007/06/12/gnu-screen-and-my-screenrc/
http://technique.sonots.com/?UNIX/設定、設定ファイル/.screenrc