If the changes on your branch diverge from the changes in your stash, you may run into conflicts when popping or applying your stash. There is no explicit 'abort' command, but hitting CTRL-C(SIGINT) will abort the stash process. Quit (any hunks that have already been selected will be stashed) You can hit ? for a full list of hunk commands. So yeah, squashing is a bit of a pain, but I would still recommend it over heavy use of stashes.$ git stash -p diff -git a/style.css b/style.css new file mode 100644 index 0000000.d92368b - /dev/null +++ b/style.css +* Stash this hunk ? y diff -git a/index.html b/index.html index 9daeafb.ebdcbd2 100644 - a/index.html +++ b/index.html + Stash this hunk ? n S 310154e updated README formatting and added blame You will get the opportunity to change the commit message, too. To squash all commits of a branch down into a single commit, keep the first commit as 'pick' and replace all subsequent 'pick' entries with 'squash' or simply 's'. # However, if you remove everything, the rebase will be aborted. # If you remove a line here THAT COMMIT WILL BE LOST. # s, squash = use commit, but meld into previous commit # e, edit = use commit, but stop for amending Pick 310154e updated README formatting and added blame Here's what you will see when you type git rebase -i master bug1 pick f7f3f6d changed my name a bit Pretend you have the following commit history, and you want to rebase & squash bug1 onto master: F < bug2 I'll steal their example verbatim for convenience. Pro Git is an awesome book which is also online in HTML format, and has a nice section on rebasing & squashing: When you do this, you have the option to pick what you want to do with each commit. When you rebase one branch onto another, you can do it interactively (the -i flag). It's much harder to screw up already existing commits. If you have a dirty working directory and you pop a stash, you can't 'undo' that pop. And more importantly, if you screw something up you can't revert. Stashes are a bit messy in a git log graph. But having tried this, I personally find it troublesome. Atleast that saves you the staging issue. Well, you can go back to stashing for each bug, and only work with one bug at a time. And this avoids a complicated stage/stash dance.Īnswer to ctote's question in the comments: One bug at a time in your workspace, but with using local branches your repository can handle multiple bugs. Then you can push, delete your local bug1 branch, and off you go. This will result in the following: D < bug2 When your code has been approved, you can rebase it on to master with the following steps: git checkout bug1 Let's pretend that someone else commits E & F on master while you're waiting on review. Make changes, commit, wait for code review. Go back to master with git checkout master. This is local, so you're not affecting anyone else, and it should be easy enough to make a patch from git diffs.

Make some changes, commit, wait for code review. That way you can use local branches & rebase, which I find far easier than managing a complex stash/stage. Is it absolutely necessary to work on several bugs at once? And by 'at once,' I mean 'having files edited for multiple bugs at the same time.' Because unless you absolutely need that, I'd only work on one bug at a time in your environment. Stashing only staged changes in git - is it possible?

Git stash new files