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?

  • What's the equivalent in Git to a read-only component in ClearCase?
  • Git with VS 2013 throws error on sync
  • Git merge showing 'rename/deleted' for file really renamed in both branch
  • Adding a git commit message using vi on OS X
  • how to finish reverting a commit, and how to revert a lot of commits
  • git2go fetch remote tags
  • Is git dot notation in its commands a part of something more generic?
  • Stashing without changing the index or the working tree
  • how to alias git flow hotfix finish
  • Git Revert “revert is not possible because you have unmerged files”
  • Copy a git repo without history
  • Switching branches in git
  • 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.