Git: branching, forks and upstream repositories.

So, today’s blog post will have a bit more of a tech focus, more specifically focusing on some fun I had with this site last night. Might even be that I write something that’s useful to someone, but let’s not hold our breath where that’s concerned ;).

This site is built on top of the FoundationPress theme by olefredrik. I picked it, because I’ve enjoyed working with Zurb Foundation, a very nicely built front-end framework. And while I could have done this theme from scratch (actually did a theme from scratch using Foundation ones for a class at Arcada), sometimes it’s nice not to have to reinvent the wheel. Beyond that I find that modifying an existing theme or template can be just as much a learning experience as creating a new one from scratch, or even more so.

So, to create this theme I downloaded a basic copy of FoundationPress, modified it to my liking and added it to a private git repo. So far, so good. A few months after creating this blog I noticed a bug and went to check the FoundationPress site for solutions, and lo and behold, this issue wasn’t only known, it had already been patched. Checking out some of the other changes that had been made since I downloaded my copy there were also other bugfixes and new features (such as changing from Grunt to Gulp). But what was I to do? I had made changes to the theme, but hadn’t tracked them from the start. And since this wasn’t a branch of the original project I couldn’t rebase it either.

My first thought was to fork the original repo and then do my best to find and apply my changes. While this was by no means impossible it would’ve been a nuisance to find every change and the repository would have had to been public, since the original one I forked it from was public. I could just have cloned the repo again, but then a few months down the road I’d be back where I started. That’s when I found the solution; add the original repo as a upstream repository and merge it into my branch. Sounds easy, right?

Well, it wasn’t actually that bad, but easy it wasn’t. SourceTree is a brilliant tool for git management and it helped me track which files had changed after the merge. Then I “just” had to resolve merge conflicts and that’d be that. Well, anyone who’s had to solve a bunch of merge conflicts knows that it’s not exactly a pleasant task, but luckily I found another tool for this, DiffMerge. SourceTree can open conflicts in DiffMerge, then you get to pick which file to base the merge on and cherry-pick the changes you want from the other. While still a cumbersome task, this made the whole process a lot easier. My only real issue was that for some reason every time I completed editing a file with DiffMerge and saved it SourceTree crashed… But the changes were stored, so was just a nuisance to keep restarting SourceTree. I blame this one on Windows…

So, now I have a repo with an upstream branch and in the future merging in new changes should be A LOT easier… Hope you enjoyed the read and maybe learned something; that’s all folks!

Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>