What is the right strategy of maintaining and combining branches with big differences in behind and ahead

Question

At the moment I am maintaining two branches. A source branch and a derivate of it. They have to be both in sync because in the future they will be merged. The policy is that every two weeks the branches are synced / merged. As you can see the 'fork' is 97 behind and 217 ahead.

I tried to first merged one to another and visa versa in Team explorer but they are both ways up to date. Pull requests have a lot of merge conflicts. Not a problem because I will solve them. But how can I solve the merges when both branches are up to date.

Answer 1

tl;dr: For maintaining Fork/development, I would prefer a rebase strategy if possible, and fall back to a merge strategy in cycles where rebase is not possible (which might possibly be always).

Here's a breakdown of your typical two week cycle. You could always begin with:

1. Merge Fork/development into development. This would probably best be done with a Pull/Merge Request using a SCM, but if not, conceptually it would be similar to these commands:

git checkout development
git pull
git merge --no-ff Fork/development  # resolve conflicts if needed

2. Now delete and recreate Fork/development from development so it starts fresh again. This could be accomplished with these commands (assuming your remote is called "origin"):

git fetch
git checkout Fork/development
git reset --hard origin/development

3. After step 2 both development and Fork/development are equivalent (synced). Now work in Fork/development for the next two weeks using either a rebase strategy or merge strategy. (Differences explained below.)

During your two week cycle there is some personal preference here on which way to go, but based on the comments, as the sole person committing to Fork/development, it sounds to me like you can treat Fork/development just like a regular feature branch that happens to persist. In this case I would recommend keeping it up to date with development with a rebase strategy until the next time it is merged back into development in two weeks. If you are able to use this strategy, your typical day might look like this:

git fetch
git checkout Fork/development
git rebase origin/development # resolve any new conflicts if there are any
# Commit
# Commit
# Commit
# etc.

Note this only works if you don't have any new merge commits in Fork/development that you need to keep, but if you are straight committing into the branch you typically wouldn't have merges. Just keep rebasing often so that if a conflict crops up, you handle it early and resolving it is easier. When I have long running feature branches I typically rebase onto (what we call) origin/develop multiple times per day. Another thing that helps keep your branch cleaner is to interactive rebase regularly too. In a typical day I might create 20 commits, and at the end of the day I will use an interactive rebase (rebase -i) to reorder and squash those commits down to, say, 2 or 3 commits before rebasing onto origin/develop. After two weeks I may have committed hundreds of times, but I probably have less than 10 "perfect" commits by the time I create my pull request. Depending on what each of your commits are, this may or may not work for you. The biggest downside of the rebase strategy is if you do have conflicts regularly, you'll have to resolve them more often when you rebase onto origin/development, and possibly in individual commits as it replays all of your commits on the branch. At the 13 day mark if you have 100 commits that modify the same files, you may have to resolve conflicts multiple times for a single rebase (though perhaps a meaningful squash there first could lessen the pain). Another thing that would help enable the rebase strategy is when conflicts arise during a branch rebase, resolve them and then merge your branch back into development soon after. Obviously you can only do this if you are allowed to sync up the branches prior to the 2 week mark.

I would strongly prefer the branch and interactive rebase strategy if you can do it, but if for some reason you can't, then you'll have to do a merge strategy instead. The merge strategy would be similar to what your colleague offered, which is periodically you would merge development into Fork/development, and then every two weeks go the other way by using #1 and #2 above.

Answer 2

What is the right strategy of maintaining and combining branches with big differences in behind and ahead

I am afraid there is no such right strategy of maintaining and combining branches with big differences in behind and ahead.

Code collision is inevitable when we merge branches. If there is a conflict between behind and ahead contained in a branch, we have to manually resolve it.

In order to reduce the time it takes to resolve conflicts, we can try to increase the agility of development and increase the merge cycle to one week or less.