Once you know the hash of the stash commit you dropped, you can apply it as a stash:
git stash apply $stash_hash
Or, you can create a separate branch for it with
git branch recovered $stash_hash
After that, you can do whatever you want with all the normal tools. When you’re done, just blow the branch away.
Finding the hash
If you have only just popped it and the terminal is still open, you will still have the hash value printed by git stash pop on screen (thanks, Dolda).
Otherwise, you can find it using this for Linux, Unix or Git Bash for Windows:
git fsck --no-reflog | awk '/dangling commit/ {print $3}'
...or using Powershell for Windows:
git fsck --no-reflog | select-string 'dangling commit' | foreach { $_.ToString().Split(" ")[2] }
This will show you all the commits at the tips of your commit graph which are no longer referenced from any branch or tag – every lost commit, including every stash commit you’ve ever created, will be somewhere in that graph.
The easiest way to find the stash commit you want is probably to pass that list to gitk:
gitk --all $( git fsck --no-reflog | awk '/dangling commit/ {print $3}' )
...or see the answer from emragins if using Powershell for Windows.
This will launch a repository browser showing you every single commit in the repository ever, regardless of whether it is reachable or not.
You can replace gitk there with something like git log --graph --oneline --decorate if you prefer a nice graph on the console over a separate GUI app.
To spot stash commits, look for commit messages of this form:
WIP on somebranch: commithash Some old commit message
Note: The commit message will only be in this form (starting with "WIP on") if you did not supply a message when you did git stash.
Amending the most recent commit message
git commit --amend
will open your editor, allowing you to change the commit message of the most recent commit. Additionally, you can set the commit message directly in the command line with:
git commit --amend -m "New commit message"
…however, this can make multi-line commit messages or small corrections more cumbersome to enter.
Make sure you don't have any working copy changes staged before doing this or they will get committed too. (Unstaged changes will not get committed.)
Changing the message of a commit that you've already pushed to your remote branch
If you've already pushed your commit up to your remote branch, then - after amending your commit locally (as described above) - you'll also need to force push the commit with:
git push <remote> <branch> --force
# Or
git push <remote> <branch> -f
Warning: force-pushing will overwrite the remote branch with the state of your local one. If there are commits on the remote branch that you don't have in your local branch, you will lose those commits.
Warning: be cautious about amending commits that you have already shared with other people. Amending commits essentially rewrites them to have different SHA IDs, which poses a problem if other people have copies of the old commit that you've rewritten. Anyone who has a copy of the old commit will need to synchronize their work with your newly re-written commit, which can sometimes be difficult, so make sure you coordinate with others when attempting to rewrite shared commit history, or just avoid rewriting shared commits altogether.
Perform an interactive rebase
Another option is to use interactive rebase.
This allows you to edit any message you want to update even if it's not the latest message.
In order to do a Git squash, follow these steps:
// n is the number of commits up to the last commit you want to be able to edit
git rebase -i HEAD~n
Once you squash your commits - choose the e/r for editing the message:
Important note about interactive rebase
When you use git rebase -i HEAD~n there can be more than n commits. Git will "collect" all the commits in the last n commits, and if there was a merge somewhere in between that range you will see all the commits as well, so the outcome will be n + .
Good tip:
If you have to do it for more than a single branch and you might face conflicts when amending the content, set up git rerere and let Git resolve those conflicts automatically for you.
Documentation
Best Answer
I just want to this answer more clear. How to make your job to checkout a specific commit, step by step:
COMMITin my example.${COMMIT}which is the reference to the job parameter and will be resolved during the build.That's it, launch the build and in the log you will see something like this:
Note, that there are other ways to set the environment variable before the SCM checkout, i.e. using
Prepare environment for the runstep from the EnvInject Plugin (you could even use Groovy for this).Also, if you don't see the options I'm talking about or they don't work, ensure you have a new version of a Git plugin In my case it is 2.2.0.