I’ve recently joined a team with a code base which hasn’t been under version control. The code has been forked several times by different people in the organisation working on different projects. Now we’re going to start using version control and we want to merge the valuable contributions from the different projects. The projects share a common original version, so I’ve made one branch for each project and plan to start merging. Now I’m wondering what strategy to use when merging.
How would you choose the branch to start merging? The one with the least scary changes? The one with the most scary? Would you synchronize all branches with trunk after merging one of the projects into trunk? Is there a best practice to follow when working with many branches that have diverged a lot?
Or should I just stop worrying and start merging them one by one?
If you want to have smooth merge, you should make sure you include base versions for each merge into the version control system, if you have those. Just determine that one of the branches that people most branched from is a trunk and then you need to record a version on the trunk for every time someone branched from it, if you have those. Without those base versions the merges will become a mess.
If there was no version control, not even someone doing a tarball of the code at the time they merged, so you cannot reconstruct even as little as the base versions, you will need to be very careful. Put the code into the source control prior to merging anything. Try to reconstruct the branches in as approximate way as possible by what has been branched from where.
Now if your source control system records merge links between branches and keeps a good track of base versions and merges, like for example ClearCase, you want to start from smaller merges, which can be done by individual developers to reduce the work in parallel first. Then do the large merges with all developers involved.
If on the other hand you don’t have good tracking, changes from the already done merges will pop out again in the subsequent merges and you might need to redecide the conflicts again. This is quite painful so I would suggest to large merges with full team so everyone can see what has been decided and then they can keep the correct code during their smaller merges.
The main point is that without proper merge tracking, your need for someone who understands the code to be present or doing the merge increases, because he needs to identify the correct (current) chunks of code to go into the file.