How semantic versioning fits into the git workflow

I’m currently having trouble using semantic versioning with git.

We are using the git versioning model at

  • Signing tags in git
  • Hide .git directory or file with apache
  • Git merge separation
  • git clone produces different permissions on different servers
  • Heroku Create Command Yielding “ENOENT” Error
  • git push error Gtk
  • We would also like to follow the semantic versioning guidelines outlined at

    Here is a sample use case for us.

    Release branch: ----1----2----3----4 <- tag v1.2        ----7---8---9 <- tag v1.3
                       /                \                  /             \
    Develop branch: --0--------5---------4--6-----------------------------9--

    Here’s our sample use case:

    • Development occurs in parallel on release and develop
    • Release is ready to go, we tag it as v1.2. We generate release notes for changes 1, 2, 3, 4.
    • We merge release back to develop.
    • When we are ready to branch of develop again for another release, we can. However, tag v1.2 is pointing to 4, so the release notes for 5 is effectively lost if we query for changes between v1.2 and v1.3

    What we would like to do is to be able to search for all newly added checkins since tag v1.2 was created that are newly incorporated into tag v1.3 so that we can determine what kind of version bump (x.y.z) for our component we need to make.

    If 5 happened to be a major change, but everything from v1.2 onwards isn’t, we will incorrectly bump the minor version since checkin 5 was not in the build.

    Does anyone have any suggestions on how this can be solved?

  • How to “reopen” the last git commit?
  • git push -u origin master, username and password
  • Converting svn to git, how to get the branches not to be just remote in the svn repo?
  • How can I recover files after accidentally running “git clean -df”?
  • How Publisher publish message to topic in Apache Kafka?
  • Setting upstream to a submodule (or how to include a GitHub fork as a submodule)
  • One Solution collect form web for “How semantic versioning fits into the git workflow”

    I guess that depends on how you “query for changes”. But if you mean using git log v1.2..v1.3, or something like that, then that should show you exactly what you want, that is, including commit 5.

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