I'm working on a PHP app, using three main branches: 'master' (current stable release), 'bugfix' (for patches) and 'next' (for next minor version).

We store the current version number in the code - it's used for a few things including checking for updates to the app, and also simple cache-busting for CSS/JS files (like styles.css?v=1.2.3) which helps when updating.

My problem is regarding merge conflicts. Say I have version 1.2.3, and 'next' is branched off there to start work on version 1.3. I change the version in that branch to 1.3.0 or 1.3.0-dev. Then I need to fix a bug in the 1.2 line, so the 'dev' branch is patched and version 1.2.4 is released.

But now when I merge the changes into the 'next' branch I get merge conflicts, because the same line was edited in both branches. Are there any strategies to avoid this? Or should I just resolve the merge conflict and move on?

I've seen a few answers across SE that talk about using git tags (which we do use for releases) but I don't think that really helps my situation since we need the version number in the code.

  • 1
    There might be branching strategies that prevent these conflicts on the version number, but on the other hand it is a very easy conflict to resolve. – Bart van Ingen Schenau Mar 12 '17 at 7:33

The first thing is to read up and understand Semantic Versioning.

The next trick is to look into your build process and your version control system so that your build process automatically adds the appropriate tag(s) to the version based on which "branch" you are building from.

If you are happy using a little python you can generate the version value, as either an environment variable or as a generated include file by or whatever the equivalent is for the languages in use using the bindings available for most version control systems. You can also do similar tricks with bash scripts, etc., but I find the python solution a lot cleaner and more maintainable.

Personally I also set a flag if a build includes any uncommitted changes.


Put the version number in its own file and don't ever merge that file.


I have that problem quite a lot, and it takes ten seconds to resolve the conflict. So it's not something I worry about.


The version numbers not quite a part of code. I'd rather say it is meta information and ideally shouldn't be in the repository alongside with the source code. It should be added only on the building phase. But the world isn't ideal place so sometimes indeed you need to have the version hard coded in your code.

For these cases it is expectable and fine to have version conflicts on merging different versions. This fact shouldn't make you uncomfortable.

I would minimize the number of places where version is stored. Ideally it would be one particular file which contains only the version and nothing else.

You can solve this conflicts by hands, but the better decision would be to write some custom merge driver to solve that type of conflicts automatically. Example of the driver you can see in this answer.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.