monjudoh さんのバージョン管理についてのツイート (Mercurial)
(その前の文脈は分かりませんが)
Nozomu Kaneko 氏から commit の単位についてのツイート
トピックブランチで中途半端な状態をコミットするの、意図しない変更が紛れ込んだことに気がつかずにマージしてしまうケースがあるからやめた方がいいんじゃないかな。
2013-09-26 23:16:40主に多人数での開発で公開リポジトリに push する場合ね。ローカルとかプライベートリポジトリで閉じてるうちは好きに使えばいいと思う
2013-09-26 23:19:38だいたい、適切な粒度でコミットが分かれてないと変更内容の把握が大変だと思うんだけど (大前提として push 前やマージ前後に差分を確認するのは当然で、それすらしないのは論外)
2013-09-26 23:40:33BPStudy#73 に参加中と思われる hirokiky 氏のツイート
それ以外だとOSSにパッチなど投げる中で意識せざるを得なかった感。あと影響受けたのが、どこだったかgitの開発自体がコミットログを重視するという記事
2013-09-26 23:51:12@monjudoh バージョン管理とか、リポジトリに余計なコミット入れたくないとかの考えかたで、影響受けたもののうちの一つがもん様かなーとか思ってた
2013-09-27 00:29:41この話だ、面白かったの。とくにコミットログについてが良い / Git にパッチを送って取り込まれた話 - てっく煮ブログ http://t.co/rj6XpsK7YZ
2013-09-27 00:34:00monjudoh 氏の VCS 運用例について
僕のバージョン管理のやり方はdefaultとかrelease branchとか要は最終的にmergeする対象のbranchでガシガシcommit追従は逆方向mergeではなくgraftでのrebaseで
2013-09-27 00:37:43複数ticketの対応を一本に入れちゃうけどcommitの独立性は保って、ある程度できてきたら頭を整理してchangesetsの順番を変えて各ticketごとにひとまとめにして、
2013-09-27 00:40:43そしたらticketに対応するbranchを切っては対応するchangesetsをgraftしてmergeして、竹の節みたいなグラフにする。 というものです。
2013-09-27 00:42:04一番最後の奴をやる、つまりpublishするまでpushはせず、shareだけしたい時はbundle出力してticketに貼るとかする。
2013-09-27 00:44:16逆方向mergeを行うのは、分岐元の変更を取り込みたいからで、実用的にはそれを優れたmergeアルゴリズムで行いたいからで、graftならそのmergeアルゴリズムの恩恵だけ受けられる。まあGitの人はrebaseしないで逆方向mergeしといて下さい。
2013-09-27 00:49:16そっか。ブランチとかを「考える」前にとにかく書いてコミットしまくって、後からブランチに振り直せばいいのか。先にブランチありきで作業しようとすると、ブランチのことを妄想する時間wが結構かかったりするんだよなー
2013-09-27 00:56:36履歴を比較的綺麗に保つのは若干複雑化したグラフの中からエンバグ箇所やmerge漏れを探して彷徨ったり、地下鉄路線図と化したグラフについて同じような事を頼まれてちゃぶ台を返した事があるからです。後、改変前の個々のcommitが相当いい加減というのもある。
2013-09-27 01:05:18しかかり中のを一本にしておくのは一週間・二週間・それ以上の期間生存したtopic branchが並走してると往々にしてmerge困難な事態になるので。
2013-09-27 01:12:08あるbranchの成果が出来上がったというのは、分岐元に対してff merge可能&&正しく動く状態であって、branchのheadにおいて正しく動く状態ではない。出来上がったがpublishしてない状態で、分岐元が伸びたら出来上がってない状態になる。
2013-09-27 01:18:50並走するtopic branchがそれぞれ出来上がっている場合において、そのどれか一つをpublishすると他は出来上がっていない状態になる。
2013-09-27 01:20:35個々の機能を無事完成させる際に足を引っ張る出来事を減らすためにやっているので、特に余計なコストをかけてる感覚はないなあ。別に手間もたいしてかからんし。
2013-09-27 01:21:54