Git: Going back to a specific date time and retrospective tagging

I'm a fairly happy Git user :-)  It's and excellent product and a great improvement on CVS, SVN, SourceSafe, PVCS and other systems I have used in the past.

In my day to day working I've got into a pattern of using very simple commands like clone, commit, update, pull, push etc.

But then I got into the situation where my code was broken but I couldn't pinpoint exactly what had gone wrong or when this happened. What I wanted to do was to roll the code back until I reached the time when the code was last working which would allow me to determine the exact cause of the failure.

The question was how to go back in history using just the date:

Turns out that this is really easy: Just use t and retrospective tagginghe command below:

git checkout master@{2009-07-27 13:37}

If this fails because the reflog doesn't go back to that point in time then you need the command below:

git checkout `git rev-list -n 1 --before="2009-07-27 13:37" master`

Another useful thing to do is to be able to tag a build retrospectively. So for example in our scenario, let's say you've found the last working version you might want to tag it.

That's also pretty easy.

Use the command  git log to show a history of all the commits on the project.  Once you have found the commit at which you want to tag just use this command:

git tag -a v0.9 7fcea889f -m "Retrospective tag"

7fcea889f matches the start of the commit id.

You can then push them up using git push --tags origin master

Then you have a tag which will easily allow anyone to checkout that version of code.

Maven tip: Release Without Deployment

This is how you do a Maven release, as simple as this:

mvn release:prepare
mvn release:perform

This will move you up a version in your code. Say, for example your last released version is 1.2 (meaning the pom.xml on HEAD is on 1.3-SNAPSHOT), by default your release version will be moved to 1.3 and the version on the pom.xml on HEAD will be moved to version 1.4-SNAPSHOT.

A nice feature is that if you use the flag -dryRun=true on either of the above commands you can go through all the steps without any of the files being checked in. It gives you an opportunity to examine the changes to the pom.xml files before you go through with the commit.

To facilitate the release procedure you need to have these lines configured in your highest level pom.xml file.

<scm
  <connection>scm:git:git@github.com:YourRepository.git</connection
  <url>scm:git:git@github.com: com:YourRepository.git</url>
</scm>

By default the code will be built and deployed to a server.  Typically you will want to deploy to Maven Central or to a local Nexus server.  This is done using the releaseProfiles property in the maven-release-plugin.

But this will not always be the case.  If you just want to do a release of the code, to Git for example, and not deploy the code anywhere you need to override the default maven-release-plugin goal property, which by default is set to deploy and set it to install as below:

<plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-release-plugin</artifactId>
         <version>2.5.1</version>
         <configuration>
              <goals>install</goals>
          </configuration>
</plugin>