monjudoh さんのバージョン管理についてのツイート (Mercurial)

個人的に後で調べたり参考にしたかったので, 氏の運用例をまとめました. @monjudoh, @hirokiky, @naka_aki_spl, @wonderful_panda, @knzm2011 のツイートを使用させていただきました. (勝手に) 感謝. 続きを読む
5

(その前の文脈は分かりませんが)

Nozomu Kaneko 氏から commit の単位についてのツイート

Nozomu Kaneko @knzm2018

トピックブランチで中途半端な状態をコミットするの、意図しない変更が紛れ込んだことに気がつかずにマージしてしまうケースがあるからやめた方がいいんじゃないかな。

2013-09-26 23:16:40
Nozomu Kaneko @knzm2018

主に多人数での開発で公開リポジトリに push する場合ね。ローカルとかプライベートリポジトリで閉じてるうちは好きに使えばいいと思う

2013-09-26 23:19:38
Nozomu Kaneko @knzm2018

だいたい、適切な粒度でコミットが分かれてないと変更内容の把握が大変だと思うんだけど (大前提として push 前やマージ前後に差分を確認するのは当然で、それすらしないのは論外)

2013-09-26 23:40:33

BPStudy#73 に参加中と思われる hirokiky 氏のツイート

清原弘貴 @hirokiky

共有、バックアップなんかの目的でコミット、プッシュするという感覚もあると知って驚いたことある。

2013-09-26 23:21:09
清原弘貴 @hirokiky

コミットの独立性とか強く意識できたのはMQを教えてもらったことが大きい

2013-09-26 23:49:25
清原弘貴 @hirokiky

それ以外だとOSSにパッチなど投げる中で意識せざるを得なかった感。あと影響受けたのが、どこだったかgitの開発自体がコミットログを重視するという記事

2013-09-26 23:51:12
清原弘貴 @hirokiky

あともん様の話とか。

2013-09-26 23:52:35
清原弘貴 @hirokiky

@monjudoh バージョン管理とか、リポジトリに余計なコミット入れたくないとかの考えかたで、影響受けたもののうちの一つがもん様かなーとか思ってた

2013-09-27 00:29:41
清原弘貴 @hirokiky

この話だ、面白かったの。とくにコミットログについてが良い / Git にパッチを送って取り込まれた話 - てっく煮ブログ http://t.co/rj6XpsK7YZ

2013-09-27 00:34:00

monjudoh 氏の VCS 運用例について

文殊堂 @monjudoh

僕のバージョン管理のやり方はdefaultとかrelease branchとか要は最終的にmergeする対象のbranchでガシガシcommit追従は逆方向mergeではなくgraftでのrebaseで

2013-09-27 00:37:43
文殊堂 @monjudoh

複数ticketの対応を一本に入れちゃうけどcommitの独立性は保って、ある程度できてきたら頭を整理してchangesetsの順番を変えて各ticketごとにひとまとめにして、

2013-09-27 00:40:43
文殊堂 @monjudoh

そしたらticketに対応するbranchを切っては対応するchangesetsをgraftしてmergeして、竹の節みたいなグラフにする。 というものです。

2013-09-27 00:42:04
文殊堂 @monjudoh

一番最後の奴をやる、つまりpublishするまでpushはせず、shareだけしたい時はbundle出力してticketに貼るとかする。

2013-09-27 00:44:16
文殊堂 @monjudoh

逆方向mergeを行うのは、分岐元の変更を取り込みたいからで、実用的にはそれを優れたmergeアルゴリズムで行いたいからで、graftならそのmergeアルゴリズムの恩恵だけ受けられる。まあGitの人はrebaseしないで逆方向mergeしといて下さい。

2013-09-27 00:49:16
非実在naka aki @naka_aki_spl

そっか。ブランチとかを「考える」前にとにかく書いてコミットしまくって、後からブランチに振り直せばいいのか。先にブランチありきで作業しようとすると、ブランチのことを妄想する時間wが結構かかったりするんだよなー

2013-09-27 00:56:36
非実在naka aki @naka_aki_spl

ほっとくと1日の7割が「これから書くかもしれないコードについての妄想」で終わったりする。

2013-09-27 00:57:07
文殊堂 @monjudoh

履歴を比較的綺麗に保つのは若干複雑化したグラフの中からエンバグ箇所やmerge漏れを探して彷徨ったり、地下鉄路線図と化したグラフについて同じような事を頼まれてちゃぶ台を返した事があるからです。後、改変前の個々のcommitが相当いい加減というのもある。

2013-09-27 01:05:18
文殊堂 @monjudoh

しかかり中のを一本にしておくのは一週間・二週間・それ以上の期間生存したtopic branchが並走してると往々にしてmerge困難な事態になるので。

2013-09-27 01:12:08
文殊堂 @monjudoh

あるbranchの成果が出来上がったというのは、分岐元に対してff merge可能&&正しく動く状態であって、branchのheadにおいて正しく動く状態ではない。出来上がったがpublishしてない状態で、分岐元が伸びたら出来上がってない状態になる。

2013-09-27 01:18:50
文殊堂 @monjudoh

並走するtopic branchがそれぞれ出来上がっている場合において、そのどれか一つをpublishすると他は出来上がっていない状態になる。

2013-09-27 01:20:35
文殊堂 @monjudoh

個々の機能を無事完成させる際に足を引っ張る出来事を減らすためにやっているので、特に余計なコストをかけてる感覚はないなあ。別に手間もたいしてかからんし。

2013-09-27 01:21:54