2
masap @masap
git/github は、レビューで「ここ直して」って言われた後の対応が面倒くさい。該当箇所を修正して commit した後で rebase しないといけない。
なかのん&マジック @d_toybox
@masap Mercurial+Phabricatorもそんな感じですね。最新のコミットなら、hg commit --amendで済みますが、さらに積んでると、rebaseとhisteditでのマージが必要になります。
masap @masap
@d_toybox この辺を便利にしたバージョン管理システムが欲しい気もしますが、現状が限界かなあとも思ってます。

コメント

おろろ @fYe39CoQsPrbZVK 2019年1月5日
ブランチ切ってプルリクマージするだけやろ。どっからrebaseが湧いてくるんや
gyrewall @gyrewall 2019年1月5日
プルリクのマージが遅れるとマージ予定のブランチが先に進んでしまってrebaseが発生するという話では? 別に修正を求められた場合に限ったことではありませんが…
Tsuyoshi CHO @tsuyoshi_cho 2019年1月5日
fYe39CoQsPrbZVK 履歴自体から消したいからですかね? なんかそもそも運用ミスってる気がする...もしリリースのブランチだから綺麗にしたい。ならリリース候補ブランチとして修正を積んでまとてリベースしたブランチをmasterとかリリースなブランチにマージするようなフローにでもすればそこまでアレじゃないと思うんだけどな。(fixupあるし)
Tsuyoshi CHO @tsuyoshi_cho 2019年1月5日
tsuyoshi_cho プルリクが遅れても、追従するブランチをマージするだけで大概は大丈夫だけど...ただ履歴が綺麗じゃないか。
おろろ @fYe39CoQsPrbZVK 2019年1月5日
gyrewall そのケースでdevelopを再マージせずrebase選ぶなら、その現場かマネージャーがやべーやつやで。すげー気軽にamendとかforceして履歴が信頼できないやつ。
おろろ @fYe39CoQsPrbZVK 2019年1月5日
tsuyoshi_cho 普通そうやね。てか履歴を消したい、改竄したいて発想がカジュアルに出る現場怖い。どう管理すんねんそれ
ログインして広告を非表示にする
ログインして広告を非表示にする