Git Stash

This little blog post is just for me to remember my favorite "git stash" commands. It took me a little while to actually use the stash, but that is because IntelliJ provides a similar functionality called "shelving", which I had used all this time.

I use branches a lot when using Git, and the problem there is that Git usually complains if I wish to change branches, while I still have uncommitted changes in my current branch. Therefore the "stash" command is for me very valuable.

Stash your current uncommitted changes:

$ git stash

Get your uncommitted changes back from the stash:

$ git stash apply

Get a list of your current stashes:

$ git stash list
stash@{0}: WIP on master: 049d078 added the index file
stash@{1}: WIP on master: c264051 Revert "added file_size"
stash@{2}: WIP on master: 21d80a5 added number to log

Remove a no longer needed stash:

$ git stash drop stash@{0}
Dropped stash@{0} (364e91f3f268f0900bc3ee613f9f733e82aaed43)

One command I particularly like is this one that does both an apply of your stash and once done automatically removes it from the list of stashes:

git stash pop

The stash has a lot of similarities to your standard Stack implementation (or Dequeue, depending on your point of view.)

I notice that if I do not clean up the place or use the "pop" subcommand, that my list of stashes tends to grow quite long unobtrusively.

View a stash without applying:

git stash show

Actually showing the contents of the stash in diff format is:

git stash show -p

The commands above work on the latest stash in your list.

References

6.3 Git Tools - Stashing

https://git-scm.com/book/en/v1/Git-Tools-Stashing

Atlassian Tutorials - Git Stash

https://www.atlassian.com/git/tutorials/git-stash

Ariejan De Vroom - GIT: Using the stash

https://ariejan.net/2008/04/23/git-using-the-stash/

Git Stash - Man Page

https://git-scm.com/docs/git-stash

Update: added the showing of stashes without applying.

Maven and the Dangers of Snapshots

Recently we've been causing problems in the regular builds of branches of our software.

Basically the problem is our own fault and is related to Maven Snapshots.

According to the guide¹, a Snapshot is a library that is still under development, and may change rapidly as new versions of the Snapshot are pushed to the Nexus regularly.

If a dependency on a Snapshot is defined in your pom.xml, then Maven, as it should, always picks the latest Snapshot.

This is fine and dandy if you are currently developing your software, and you want the newest of the new of the libraries that your other software teams are developing.

The Problem

It means that once you create a stable release of your software (and the appropriate Git branch for it to live in as well, of course) it is important to replace the Snapshot in the pom.xml with the appropriate released version.

We neglected to do just that.

The Consequence

Our branch containing the release version of our software suddenly bombed with compile errors in the Deployment Pipeline.

This caused the maintenance people a headache, as the Git revision of the branch had not changed, between the previous build (which compiled just fine) and the new build (which bombed).

Despite the build being pulled from Git with the exact same revision, it was technically different from the previous build.

All because we kept developing the Snapshot and pushing it into the Nexus.

What we should have done

• create a proper release of the library
• change the pom.xml in the branch to refer to this release.
• create a new snapshot of the library
• use the new snapshot in the pom.xml of the master branch (which is used for development)

Now the build of both the branch as well as the master should compile again.

References

[1] Apache Maven - Getting Started

https://maven.apache.org/guides/getting-started/

Continuous Releasing of Maven Artifacts

https://dzone.com/articles/continuous-releasing-maven

Update: reference added.