Suppose you’re working on a software project and you’ve tagged your release 0.1.0. It has been shipped and now you’re working on version 1.0.0. You’re reworking quite a lot. It’s a major release after all, a lot to be done 🙂
In comes someone who sees version 0.1.0 and thinks to him/herself: “Oooh, can you maybe add some functionality on top of that? I don’t want to wait for 1.0.0, that takes too long.”
Although the ‘building a house’ metaphor is a strained one when it comes to software, it can be used to abstract away from the nitty gritty detail of software development and describe things like project management and development strategies. Today, let’s discover some of the superpowers we have in software-land, and what their limitations are. And let’s use our superpowers to build a house 😉
Version control, especially Git, grants you the powers to:
- work in parallel universes (branch)
- go back in time (branch from older release or commit in the past)
- automatically replay anything you did in a parallel universe in another parallel universe (merge or rebase)
This is convenient when we’re doing things that are unrelated. Two developers could branch from trunk (or master or main stream) and work in their own branches quite comfortably, as long as they don’t do conflicting things in the code base. Or, to strain the house metaphor to its breaking point: Someone could be installing a new kitchen while another team replaces the roof.
However, a problem could also arise that is not often understood by non-technical folk. It’s when one team wants to replace the fridge, while another team is tasked with moving the entire kitchen to the second floor. Although we could work in parallel universes, there comes a point when those two parallel universes must be merged. You may end up with a kitchen without fridge on the second floor, and your new fridge on the ground floor…
It’s even worse. Let me illustrate:
- On Monday a painter comes in to paint your front door blue. On Tuesday, he finishes the job and leaves. Version 0.1.0 is born.
- Now, for version 1.0.0, we have a big makeover in store: We’re moving the door to the left, by a meter. On Wednesday a carpenter and two bricklayers come in. They park their cars in the driveway, walk to the front door, put down their tools and get to work. They’ve been working at it ever since.
- Then, someone comes in and decides to teleport someone back to Wednesday in a parallel universe, because the customer would like the door painted white. A painter parks his car in the driveway, walks to the front door, puts down his tools and gets to work. Version 0.1.1 has a white door.
Are you with me so far? Right now, we have two universes:
One where the door is blue and moved to the left by a meter.
And one where the door is in its original place and replaced by a new, white door.
And then imagine someone wants you to merge 0.1.1 into 1.0.0…. He wants the new, white door in the major release after all. Moved to the left by a meter, of course..
Now, consider the following problems when we want to bring those two parallel universes together:
- We can’t have two cars parking in the same spot in the driveway at the same time
- Two persons and their tools can’t occupy the same spot.
- And the door can’t be both moved and in its original place at the same time
This is what we in the business affectionately call a merge conflict. This takes time to resolve and possibly some rework. Additional testing, adaptation of documentation and whatnot is needed.
So, in short, although yes, we could work on two versions at the same time and yes, they could have entirely different functionality: No, it is not always straightforward to bring changes from one universe to the other…