Merging

Merging branches is something that goes on in the real (non-computer) world all the time, but you probably never think of it. Don’t think so? I can prove it.

Everybody has two parents, four grandparents, 8 great-grandparents, and so on and so on. Go back 10 generations and you have 1024 ancestors. Go back 20 generations and you have a million. Soon enough you run out of people on the surface of the earth even at today’s population of about 6.5 billion: 33 generations or 660 years back there were far fewer than the 8 billion ancestors than this simple calculation would suggest. Clearly, what’s happened is that genetic lines would have to merge occasionally – that is, cousins, or second-cousins, or however distant, would have to get married to each other in order for the combinatorics to not explode. Yes, everybody around you is truly your brother or sister.

Branching is similar to having children except that in the computer world, often the parent branch lives on much longer than the children. That’s a significant feature of branching that I will return to later. But for now let’s think about what merging is.

To merge two development lines is to take the changes in one line and bring them back into the other. A common scenario is when you have done some custom development for a customer, then you decide you want to bring those changes back into the “main line” of development. Graphically, it might look like this:

In practice you don’t always take all the changes from the branch and merge them in. Sometimes a branch has a number of irrelevant changes that you want to leave out when you’re merging. Sometimes the changes in the branch are ongoing and your goal during the merge is to bring in some straightforward fixes while allowing the branch to continue development. This is where life gets really complicated. You are not dealing with just one file: The changes in a given project can be spread out over many files. How do you know which changes belong to one feature, and which belong to another feature?

When I want to craft an explanation of something complicated, I use the “would my mother understand it?” metric. Now my mother, who is a wonderful person and whom I love very much, is not a member of the computer generation so I have trouble explaining to her what I do. Early in her paid career she worked for the city of Toronto sanitation department in the division that enforced sanitation standards, including standards for backyard privies. (She made phone calls and wrote letters – she didn’t do inspections…) Yeah, that’s a while ago. She’s not technical, but she’s smart and practical. So I tell her that working on a component consists of working on a series of features of that component. Then I tell her that some features are developed in one code line while other features are developed in another code line. Then I say that we want some features developed in the first line to merge with the features in the second line, but I’m losing track of which features correspond to which work. Well, what she says is, “why don’t you group the work you do with the feature that requires it?”. Aha! That sounds correct!

Indeed that is part of the way we remove some of the complexity of merging: You make sure that each feature is associated with the work done to effect the feature. This grouping is often called change sets, or change packages. Each feature contains one or more of these change sets, and each change set consists of one or more specific changes to files or artifacts in the repository. When it comes time to merge from one branch into another, you select the features you want then move the corresponding change sets.

Is this easy? Is this painless? No way. Never was, and probably never will be. But visualization techniques can help reduce the pain. As usual, when the model becomes complicated, the UI must rise to the occasion – you will eventually recognize this as a constant theme throughout this blog.

There is one ERP package I know of that has no mechanisms to group changes together by feature, and for this package a simple version upgrade of the base product can literally take a team of developers months to do. By associating changes to features, and with the use of appropriate UI, this process can be cut down to days, if not hours.

In summary, merging is simple to understand at a superficial level but quickly gets bogged down in complexity, but with the introduction of process information and an appropriate user interface, you can reduce the complexity to a manageable level.