🌞


Note that this blog post has been archived. Information may be out of date or incorrect.

Keeping track of foreign codebase modifications with Git

I’ve been there a lot: I’m using some kind of existing framework / tool / open source software which is awesome, but there is that tiny little thing that annoys me, and I’d like to change it. No problem, I say, and start hacking. Two months later I update the codebase and my change is gone, which I don’t notice right away, but only after another month. Then I remember that I changed something, but I don’t remember how or when and the search starts.

The described situation is one that I will be able to (hopefully) avoid from now on, and here is how: Of course it involves Git and branching.

The naive solution

The naive solution to this problem would be creating a branch “modifications” containing all the hacking, and then merging it into the master branch. Your history would look something like this:

?
|
* 6dc6c93 | v1.1.0 of Awesome Framework
* 5e7d249 | Merge branch 'modifications'
|\
| * 7256352 | Don't do weird stuff
| * 0573b96 | Great enhancement
|/
* 180673a | v1.0.0 of Awesome Framework

But what would happen at the question mark? You can’t merge modifications again, because all the commits are already in the master branch, so nothing will happen (or in other words, modifications already is fully merged).

One could go with cherry-picking the commits in modifications all over again, but the problem is that they are a bit hard to get a hold of, because you can’t do master..modifications as the commits are on master too.

A working solution

My current solution for this problem also involves a branch where I keep all my modifications, but the merging is backwards compared to the previous approach. Instead of having an extra branch for my modifications, I’ve got an extra branch with the original codebase, say original. My own changes are committed on the master branch as one would usually do. Whenever I update the original codebase, I update the original branch and then merge it into master, for example:

...
|
* 14d672f | Merge branch 'original'
|\
| * 0cebd2d | v1.2.0 of Awesome Framework
* | b83105d | hack hack hack
* | 5df562e | More fancy hacks
|/
* 5e7d249 | Merge branch 'original'
|\
| * 6dc6c93 | v1.1.0 of Awesome Framework
* | 7256352 | Don't do weird stuff 
* | 0573b96 | Great enhancement 
|/
* 180673a | v1.0.0 of Awesome Framework

If you never merge your modifications into the original branch, conflicts between your modifications and the original codebase updates will be properly detected by Git and you don’t have to worry about loosing your precious hacks.

And they all merged happily ever after. :)

What I just wrote may or may not have been obvious to you as an advanced Git user, but I needed to figure it out myself and it helped me better understand how Git works.

If you have a better / different methodology feel free to drop a comment as I’d be interested to hear about it.