Explore optimal Web IDE flow for commiting to branch that already has a newer commit

@smcgivern brought up the following scenario in https://gitlab.com/gitlab-org/gitlab-ce/issues/59023.

  1. Create a file.
  2. Open it in the web IDE.
  3. Make a change but don't commit it.
  4. Elsewhere, make a change to a different part of the file, on the same branch.

The next step would currently look like this:

image

@pslaughter mentioned that there might be another option to solve this, which resembles git rebase:

  • If no conflicts, I'm good to go (I'd probably like to run my tests again though).
  • If conflicts, I need to resolve manually first (and should definitely run my tests again).

In the Web IDE, this workflow slightly differs because we combine git commit && git push. So option 1 would look more like git stash && git pull && git stash pop (which may or may not cause conflicts). Most of this can be done, because now we have a way to capture our Web IDE changes 🚀.

We should explore which option(s) we provide the user with and how these flows would look like in detail.