松尾です。

> 各commitの妥当性チェックは、本質的には単にmergeするのとかわらないのでは
> ないでしょうか?実作業上の問題としては、ChangeLogが頻繁にコンフリクトし
> てしまうのでその解決が面倒というのはありますが。

mergeするときにはそのmerge commitだけについて確認すれば
良いですがrebaseの場合はpatchが当たるかどうか、動作は
意図した通りになるかcommit毎にチェックする必要があり
ますよね。

http://github.com/hayamiz/twittering-mode/commit/52786fe52d12ca4aaa5ad060bbbfa27e2e3d12d4
のように大きな更新を越えてrebaseするときはconflictして
なくても意図した配置になるのか気になります。

先程改めてtimeline-specをrebaseしてみましたら
twittering-mode.elのconflictを2回手動修正する必要が
ありました。(ChangeLogは5回)
もっと苦労したような記憶があったのですが、慣れてないせい
だったのかもしれません。

> トピックブランチを取り込む際にrebaseすることの利点は、ひとえに履歴のシ
> ンプルさだと思います。リリースノートを書くのに見直しやすいというのもあ
> りますし、あまり事情を知らない人が履歴を見たときにどれが幹なのかわかり
> やすいというのは重要だと思います。

どれが幹なのか、についてですがmaster branchのfirst parentを
辿るものがmainlineになるんじゃないでしょうか。

git help log
--first-parent
    Follow only the first parent commit upon seeing a merge commit.
    This option can give a better overview when viewing the evolution
    of a particular topic branch, because merges into a topic branch
    tend to be only about adjusting to updated upstream from time to
    time, and this option allows you to ignore the individual commits
    brought in to your history by such a merge.

http://progit.org/book/ch6-1.html#ancestry_references
にも
The first parent is the branch you were on when you merged, and the
second is the commit on the branch that you merged in...
と書かれています。

git log --first-parent

で見えるものがそのbranchの幹で、githubのnetwork表示もそれに
沿ったものになっているように見えます。

---
松尾 直志 <t...@mymail.twin.jp>

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
twmode-users mailing list
twmode-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/twmode-users

メールによる返信