Git & CI: How to tag if build passes/revert commit if fails?

I am trying to setup jenkins for continuous integration with my python repo. I have everything working in that it will poll for updates to the repo and then run nosetests and either succeed or fail depending on the result of the tests. If the tests pass, I want it to tag the commits from the latest push with build number (“v1.0.$BUILD_NUMBER”). If the tests fail, I want it to revert to the previous tag.

What is the proper way to tag the commits from the latest push?
What is the proper way to revert if it fails?

  • Could we use Travis CI for Gitorious?
  • How to avoid a commit/release loop with Maven and CI?
  • TeamCity push feature branches to master branch
  • How to build a pipeline of jobs in Jenkins?
  • git workflows: how to integrate and test feature branches without continuous delivery?
  • Unable to start browser from Jenkins CI
  • I am getting confused on subtleties of annotated vs lightweight tags and revert vs reset. Especially the latter can really screw things up if used incorrectly.

  • Do I need to do a Git Clone?
  • Can git submodule update be made to fetch tags in submodules?
  • Get the list of changed files after a pull with JGit
  • How to suppress confirmation “Launch '$difftool' :” iff (if and only if) a specific file is passed to git difftool?
  • RW Access git repository using svn (git-svnserver)?
  • nirvdrum svn2git fetch from interrupted clone
  • 2 Solutions collect form web for “Git & CI: How to tag if build passes/revert commit if fails?”

    revert creates a new commit that includes the inverse content to the content of the commit you’re revert.

    The git repo before:


    git revert C

    The git repo after:


    C’ is an inverse commit to C.

    reset sets a new value (SHA) to a branch (like it was a pointer). Do neither produce nor deletes a commit. Resetting a branch that is shared between several developers is considered as a “brutal” behavior and will put your co-developers in a problematic state so if they aren’t aware of the reset they might merge the commit (you wanted to remove) again.

    The git repo before (current branch is master):


    git reset B

    The git repo after:


    The master branch now points to commit B. Commit C is there but nothing points to it, so it will be garbage collected probably.

    From AlBlue’s Blog

    An annotated tag creates an additional tag object in the Git repository, which allows you to store information associated with the tag itself. This may include release notes, the meta-information about the release, and optionally a signature to verify the authenticity of the commit to which it points.


    A lightweight tag holds nothing except of the SHA of the commit it was stacked to.

    Wouldn’t it be much easier for everyone if you would configure jenkins to merge with master before the build and test. Then, if tests pass, jenkins can push the result to master. If tests fail, there is nothing to revert.

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