When trying to keep my feature branch up to date with the master branch, I have to merge the master branch to my feature branch from time to time.
Is it correct that if such a merge succeeds, it will create a new commit on the feature branch?
If such a merge fails, I will have to manually resolve the merge conflict. In such a case, is it a good idea to make a commit which includes both
- the changes which I make for resolving merge conflict
- and some work I do on the feature branch?
Or shall I make separate the changes I make for resolving a merge conflict and the work on the feature branch into different commits?
Does it make a difference for later on
- others' code review on my own work on the feature branch when I create pull request for merging the feature branch into the master branch
- my self reminding of my own work on the feature branch
- other things that I miss to mention above?
Generally, how shall I arrange merge from the master branch into my feature branch and commit of my own work on my feature branch?
It is true that a merge from master to a feature branch will usually produce a new commit for the merge. You could contrive an exception to this rule, but more or less only if the feature branch doesn't have any commits on it yet. If you want to make absolutely sure a commit is created, you could merge with the no-ff option.
My advice is to put as few changes as possible into merge commits. There are a few related reasons.
First, the merge is supposed to represent the confluence of two lines of work. The merge commit message is usually something like "merged master into some_feature"; if you do additional work you'll need a commit message that lists the unrelated things you did, and it's possible - maybe even likely - that such messages will be missed when someone's looking for your change later.
For that matter, default log output for a merge commit doesn't include a patch. You can get one, but it's a 3-(or-more)-way patch which is much harder to read. So if you want to be able to easily examine your changes, don't tack them on to a merge.
Next: Down the road you might care to know what change introduced a bug. In general having overly-complex commits that do too many things will reduce the effectiveness of tools that help you narrow this down (like bisect). And "merging from master broke my feature branch" likely has a very different resolution than "the latest work I added to my feature broke my feature branch".
There also are situations in which git kind of assumes that a merge is just a merge. I'm thinking mostly of rebase operations, and it may rarely or never come up that you would rebase through a merge like this. But if you do, and if the merge contains unrelated changes, you'll have unnecessary problems.
It also happens occasionally that you have to manually "redo" a merge; and again, this is harder if you included unrelated work in the merge.
