[過去ﾛｸﾞ]
Git 17 (1002ﾚｽ)
Git 17 http://mevius.5ch.net/test/read.cgi/tech/1599016710/
上
下
前次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
抽出解除
ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索
歴削→次ｽﾚ
栞削→次ｽﾚ
過去ﾛｸﾞﾒﾆｭｰ
639: デフォルトの名無しさん [sage] 2021/04/23(金) 22:33:21.98 ID:wdsr0BNZ >>636 プロジェクトごとに考えは違うと思っていて、何を大事にするかで変わると思っている派の意見として聞いてください。 個人的には逆マージを採用します。 理由としては、コンフリクト解消のコミットを除けばfeatureの変更もリベース同等にわかりやすく、featureブランチの担当者に負担をかけないので、バランスがいいと思うからです。 解消のコミットが本質でないのはそうですが、避けられないものなら、feature実装と解消を分けて考えられるので、不具合があった場合の混入原因の特定のしやすさ→その後の改善にも繋げられると思います。 リベースの場合は、上に書いたことの裏返しでもありますが、場合によってはコミット集合を作り直す必要があると思います。 また、作り直している間にmasterやdevが更新されてたりすると、ああ面倒。このようなケースで、コンフリクトが起きる頻度は、PJの規模や同時に走っているtopicの関係にもよると思いますが… 逆マージでは最後に払うツケを、リベースでは毎回払う可能性がありますよね。わたしはそれが開発のスピードを損なうノイズだと思っています。もちろん規模によります。 でも後で見たときにはキレイなので、そこにはメリットがあると思います。 保守性のためにコミットをきれいにしておくのは大切だとは思いますが、経験上diffとblameでなんとかなる場合が多いと感じていて、将来必要とされないことに時間をかけるくらいなら、現状の開発速度に重きをおいた方がよい、というのがわたしの主張です。 的を外していたらすみません。 http://mevius.5ch.net/test/read.cgi/tech/1599016710/639
641: デフォルトの名無しさん [sage] 2021/04/23(金) 23:01:37.12 ID:PpQLqqbV ありがとうございます！ >>639はほぼ私が考えていることと合致していて安心しました >>638のケースは作業自体はリベースの方がかえって大変ですよね 逆マージはその代わりもっとログが汚くなるのでトレードオフかなと >feature実装と解消を分けて考えられるので、不具合があった場合の混入原因の特定のしやすさ→その後の改善にも繋げられる 特にこれが正に私が逆マージ派である理由なんですが、>>637は意見対立してますね できれば>>637の理由が聞きたい… http://mevius.5ch.net/test/read.cgi/tech/1599016710/641
ﾒﾓ帳
(0/65535文字)
上
下
前次
1-
新
書
関
写
板
覧
索
設
栞
歴
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
1.414s*