Improve workflows with uncommitted changes

We’ve heard a lot that users want to be able to stash changes in the working directory and that they have to leave GitHub Desktop and do this on the command line. We wanted to take the opportunity to clarify the problem statements as we explore potential paths forward in solving the problems.

More about the history of these problems and how people are experiencing them can be found in #1633 and #2304.

1. I realized after I started doing work that I actually wanted to be doing that work on a different branch. I want to be able to switch branches and retain the uncommitted changes I’ve made without having to leave GitHub Desktop.

2. I’m doing work on a branch, and something comes up where I need to temporarily go to a different branch to do something entirely different. I’m forced to either WIP commit my work and undo it when I come back or leave Desktop to stash it temporarily. I want to just be able to switch branches, do whatever I needed to do, and come back with my changes right where I left them.

3. When I pull from the remote and there are uncommitted changes, if the uncommitted changes conflict with the commits I’m attempting to pull, I’m not able to pull unless I either commit or stash my changes and deal with the conflicts later. This is true for both regular git pull and git pull --rebase. We’ve decided that this is not in scope for our initial work.

Of note, we had a feature on an earlier version of GitHub for Mac that attempted to solve problem 2 with “magic stashing,” which auto-stashed your uncommitted changes on a current branch when you switched branches, and auto-popped them when you returned to the original branch.

@shiftkey noted some pitfalls with this approach (capturing here so we consider them in any proposed solutions):

• “Magic stashing didn’t restore uncommitted changes after syncing”
• “Magic stashing can fail to restore changes with no indication that they still exist”
• “Magic stashing may delete ignored files”
• “Magic stashing fails if untracked files conflict”
• “Magic stashing information will be lost if a repository moves on disk”

The first two problems are almost certainly related and should not be considered in isolation.

[ampinsk]

Designs

Hey all! Here’s a general idea for the current design direction for uncommitted changes and stashing. This is where we’ve landed after a few rounds and internal discussion, but this is very much still open for feedback.

Problems to solve

To reiterate from above…

I have uncommitted changes. I want to:

1. Move this stuff to another branch
2. Go to another branch, keep these uncommitted changes here until I come back
3. ~Pull while I have uncommitted changes~ out of scope

Where does this fall on a spectrum from:

Literally stashing <--------------------X-------------------> Magic

Through exploring this, we felt that too magic hid too much of what was going on, and wouldn’t teach users about important concepts. But, leaning too much into stashing felt too advanced and unintuitive.

Constraints

We’ve talked about starting with these constraints to simplify what we’re grappling with:

• We will only show stashes initiated through this flow in Desktop
• We will only show a most recent, single stash per branch

Main flow

Here’s the main, happy path flow. In this scenario, imagine this is someone working on a feature branch who wants to move to master, and wants their changes to stay on the feature branch.

• Users will only (at least at first) create stashes when switching branches.
• We’ll prompt them with a modal asking what they want to do with their uncommitted changes.
• If they want their changes to stay, we’ll create a stash for them.
• When they return to that branch, they’ll be able to click into and see their stash, clear and apply/pop it.
• This also encourages the current default behavior of taking uncommitted changes with you to a new branch

Overwriting a stash

Considering we’re only going to show a single stash, if a user initiates a new stash, we’ll need to warn them.

Running into conflicts

It’s possible when applying stashes that users will run into conflicts. We can warn them about these like so:

Applying a stash with uncommitted changes

Git actually will throw an error if you try to apply a stash when you have other uncommitted changes. So in this case, we can disable the Apply button and show a note why.

Here’s an overview of all the screens I showed here if you want to poke around in detail:

Clarifications

What happens if you change the name of one of the stashes on the CLI?

Desktop will lose knowledge of that stash, but this feels like such an edge case that we don’t intend to solve for it unless it becomes a broader problem.

What happens if conflicts occur when switching branches and bringing changes over?

For now, we’ll use the current default behavior of Git and how Desktop handles it today. If it becomes a problem people are having issues with, we’ll address it after shipping v1.

What happens if you delete a branch and there’s a stash associated with it in Desktop?

The stash remains in the list and available via the CLI, but it’s no longer visible in Desktop.

Feedback

• Does this overall flow feel right for the problems we originally outlined?
• Do these constraints make sense?
• What language makes sense in terms of Apply, Pop? Maybe we can abstract these to icons to avoid confusion.
• Anything else I haven’t considered or mentioned here?

Open to any and all comments! ✨

[Janpot]

1. No, usually changes aren’t committed until after 7. And if they are, they can be undone easily with the desktop client, or I use the CLI again to rebase on top of master. usually this situation happens because my PR1 is waiting for code review. Sometimes I’m deliberately in this situation if task2 depends on PR1
2. Seldom in my workflow. Our team is small enough and is working on diverse enough code that we don’t often run into each other. It’s usually just conflicting with my own previous changes. If github desktop (or even git on the cli) could just pull master in the background that would be a perfect solution for me. In that case there wouldn’t be conflicts anymore.

stashing or rebasing my branch on top of master are maybe 80% of the cases that I switch to the CLI for