May I make code changes while resolving merge conflicts?

I have a "best practice" question about resolving merge conflicts.

Let's say I have master and need to merge a feature branch into it which introduced logging facilities. Further, let's say that during the merge, I get conflicts because some print statements in master were modified which were replaced with logging statements in the feature branch.

Now, during manual merge resolution, would you say it is permitted for the person开发者_如何学JAVA resolving the conflicts to also replace code which is related to logging but was not yet handled in the feature branch? E.g. in the code block which contained a conflict, a new print statement was also added in master. As it was not yet in the feature branch, it would remain in the merged code unless someone replaced it with the correct logging statement.

Or should merging only touch actual conflicts, leaving all inconsistencies such as those above for future commits?

I would never make a change in a merge.

• That code has not been tested whatsoever. Untested code should not be commited.
• You might obscure a bug caused by the merge itself. At least with a merge, you know you have 2 working branches.
• When someone else looks at the history, they will see a merge happened, one doesn't expect further code changes.
• Diffing the code change plus the merge is more difficult than diffing the change or the merge itself.
• There is no way to atomically rollback your inconsistency fix if you did it in a merge, you would have to roll back everything, and re-merge.

Do the merge, then do the change, otherwise you are asking for pain and confusion.

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.