Branching strategy when utilizing open source application

Question

I'm looking for advice on what a good branching strategy looks like when using mostly open source code. Most of my dev experience is with writing and working with custom made code and only using open source libraries so I'm a bit out of my dept here.

The aim is to use an open source application and make mostly minor and a few major changes to the code for our companies usage. We may also want to push bug fixes upstream sometimes.

My key concern is how to handle version updates. Whats the best way to merge our custom changes into the main code once an update is available without creating multiple repos? This will happen a couple of times each year, we aim to be no more than 1 version behind the latest version.

My current plan is to create a new branch to pull the new version into, do a diff between this and the current dev branch and then merge the code in a third branch until merges are complete and stable. This will now become the new trunk and the old one tagged as an older version. Any changes that need to be pushed upstream will be added to the first branch.

Suggestion and improvements welcome.

Answer 1

Git is not for versions. More precisely, git makes it easy to track project history, but does not make it easy to maintain a different variant or edition of a project.

Your suggested strategy of regularly merging your modifications with upstream changes is fine and may be unavoidable. However, you will have to merge the same differences again and again. So this is only bearable if your modifications stay close to the upstream code base, and if you only do fairly minor changes.

In general, the better approach is to not modify the upstream code, but to extend it using some plugin mechanism. Then, the upstream code is more like a library that you use. This lets you keep your modifications as separate code, and you won't have to repeatedly merge these modifications. This also makes it feasible to make more complex modifications.

To some degree, you can combine these approaches. E.g. only modify the upstream code to insert some hooks, and then use these hooks to insert your plugins. If the upstream project accepts a pull request with suitable hooks that is even better, because they can then be maintained as part of the upstream project. However, some open source projects may be hesitant to add hooks that are only used for proprietary extensions, so such a pull request also has a bit of a political dimension.

A note on repos versus branches: Git doesn't care. There isn't a huge difference between two repos and two branches inside one repo. In particular, every branch can be linked to its own remote repository/branch. However, if you are using tools such as GitHub then they do make a difference. If you want to make pull requests to the upstream project you need a public fork on GitHub, and all branches in that fork will be public. That means that you might need multiple forks: one where you push all your branches for internal collaboration in your project, and one where you only push branches that are supposed to be public.