2

マージの競合の解決に関する「ベスト プラクティス」の質問があります。

マスターがあり、ロギング機能を導入した機能ブランチをマスターにマージする必要があるとしましょう。さらに、マージ中に、マスターの一部の印刷ステートメントが変更され、機能ブランチのログ ステートメントに置き換えられたため、競合が発生したとしましょう。

さて、手動でマージを解決する際に、競合を解決する人が、ロギングに関連しているが機能ブランチでまだ処理されていないコードを置き換えることも許可されていると思いますか? たとえば、競合を含むコード ブロックでは、新しい print ステートメントも master に追加されました。まだ機能ブランチに含まれていなかったため、誰かが正しいログ ステートメントに置き換えない限り、マージされたコードに残ります。

それとも、マージは実際の競合にのみ触れ、上記のようなすべての矛盾を将来のコミットに残すべきですか?

4

2 に答える 2

3

マージで変更を加えることは決してありません。

  • そのコードはまったくテストされていません。テストされていないコードはコミットしないでください。
  • マージ自体によって引き起こされたバグを不明瞭にする可能性があります。少なくともマージでは、2つの作業ブランチがあることがわかります。
  • 他の誰かが履歴を見ると、マージが行われたことがわかります。それ以上のコード変更は期待できません。
  • コードの変更とマージを区別することは、変更またはマージ自体を区別することよりも困難です。
  • マージで行った場合、不整合の修正をアトミックにロールバックする方法はありません。すべてをロールバックして、再マージする必要があります。

マージを実行してから変更を実行します。そうしないと、苦痛と混乱が生じます。

于 2010-11-12T20:27:07.120 に答える
1

I would recommend that during a merge, you change only the code related to the merge. Then, once the merge is done, go back and fix the inconsistencies.

You definitely don't want to leave the inconsistencies for someone else to deal with, because it might be a long time before someone else notices them.

于 2010-11-12T20:25:05.317 に答える