[過去ﾛｸﾞ]
Git 17 (1002ﾚｽ)
Git 17 http://mevius.5ch.net/test/read.cgi/tech/1599016710/
上
下
前次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
抽出解除
ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索
歴削→次ｽﾚ
栞削→次ｽﾚ
過去ﾛｸﾞﾒﾆｭｰ
636: デフォルトの名無しさん [sage] 2021/04/23(金) 21:50:55.54 ID:PpQLqqbV featureブランチでの機能追加とテストが完了した後masterへのマージでコンフリクトが発生した場合、逆マージ(masterをfeatureにマージ)とリベースどっちで競合解決するのが普通なんでしょう？ 身内で以下のような感じで意見割れまして >逆マージ派 コンフリクト解消前のコミットログがそのまま残るので、コンフリクト解消後のテストで解消前には発生しなかった不具合が起きた場合に原因を追いやすい Gitは切り戻しを担保するのも役割の一つであり、ログの見やすさのために情報を欠落させるべきではない >リベース派 コンフリクト解消のコミットログは機能追加において本質的な修正ではなく、履歴を追う際ノイズになるので残すべきではない コミットの単位が適切であればコンフリクト解消時にミスがあり不具合が発生したとしても原因特定に苦労することはない http://mevius.5ch.net/test/read.cgi/tech/1599016710/636
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
642: デフォルトの名無しさん [sage] 2021/04/24(土) 00:29:41.30 ID:v8PWrE/P >>636読んで逆マージ派なのかなーという気はしていましたが、 リベース派の知人の意見を整理してみるのもいいかもしれないですね。 リベース派の理由が曖昧な感じがします。 コミットの単位が適切であれば…苦労することはない、の部分が理由としては弱い気がするので。 まあここには省いて書いたのかもしれないですが。 http://mevius.5ch.net/test/read.cgi/tech/1599016710/642
ﾒﾓ帳
(0/65535文字)
上
下
前次
1-
新
書
関
写
板
覧
索
設
栞
歴
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.040s