Why do I get merge conflicts when bumping the version?

I’m working on a PHP project using git/github to maintain my project. I’m following a simple branching model (master, dev, hotfix-, feature-, release). My application contains a config file (config.php) where I define the version number. Recently, I had to make a hotfix. I branched the hotfix branch from the master, made my changes, then bumped the version (ex: 1.1.2 to 1.1.3). When I merged the hotfix back into master, I had no issues. When I merged the hotfix branch into dev, I had a merge conflict with my config file on the version number line. In my dev branch, I had a different version number, so I’m assuming that’s what caused the conflict. How can I avoid this in the future? Do I need to bump the version at a different time and/or branch?

  • How can I wipe out my local branch in GIT?
  • Difference between git pull --rebase and git pull --ff-only
  • Git push origin master returns Error cannot spawn … why?
  • Git create branch where detached HEAD is
  • Require Pull Request in TFS
  • Is it possible to make git aware of an existing gitmodules file?
  • Should diff3 be default conflictstyle on git?
  • Expand git repo
  • Run batch file with git pull in gitbash
  • Safe force push procedure?
  • Can I push to more than one repository in a single command in git?
  • Version numbering / release mechanics with Maven and GitHub
  • 2 Solutions collect form web for “Why do I get merge conflicts when bumping the version?”

    No you cannot avoid this when merging – two changes to the same line in the same file end up in a conflict.

    Have you considered using cherry-picks to avoid picking the version bump? Another option would be not hardcoding the version but deriving it automatically from git (e.g. a release branch gets a number based on the number of commits and a hotfix branch a suffix based on the branch name)

    You can use a “ours” or “theirs” strategy to tell got how to resolve conflicts on its own, but I dont think you can use those strategies on specific lines. What you might want to avoid developers having to update the version number, and instead do that on a git-hook.

    A google search turned up this: http://cd34.com/blog/programming/using-git-to-generate-an-automatic-version-number/

    Alternatively, you can simply tokenize the version number and just have git ignore it completely. Have you deployment process replace the token with some derived version number – either incremental or based on the git SHA1, or some other number.

    Interesting topic, its something I actually need to do for my team soon.

    Git Baby is a git and github fan, let's start git clone.