0

I am wondering what is the correct approach in the following situation.

I am working on master branch locally and I have multiple uncommited changes that I don't want to commit to origin/master yet.

I would like to commit my current changes to some newly created origin/temporary branch (so someone else can quickly run the current stage of my workspace on his own) while keeping all the changes in local master as they are, to be able to commit them to origin/master later at some point.

I assume I have to use git stash in some order, but I am not sure...

Edit:

Some of you have suggested, that I can just merge temporary into master. This is not the case, as I'm not assuming that the temporary branch contains anything to be accepted nor anything valid. It's purpose is just to quickly show the current code stage that will change surely before it is good enough for commiting to master or to be properly reviewed.

This is the reason why I do not want to treat those changes as real changes later in the tree, they are just ugly.

Karol Sobański
  • 435
  • 5
  • 15
  • The de facto way would be to _merge_ `temporary` into `master` when work has been accepted. Why don't you want that? You can also merge in such a way (fast-forward, rebase) that it won't be visible as a merge commit, if that's the problem. Also, what have you tried? You can commit to a branch, then checkout master again and reset the status to that of the `temporary` branch. – CodeCaster May 18 '20 at 07:56
  • Does this answer your question? [How to reset a branch to another branch with git?](https://stackoverflow.com/questions/15943434/how-to-reset-a-branch-to-another-branch-with-git) – CodeCaster May 18 '20 at 07:56
  • In short, what you want is possible (but what have you tried?), but you shouldn't do it, period. Sure, your coworker can accept the changes made that are visible on some other branch, but what stops you from making one more change before committing the same changes on master? This is exactly what branching and merging are for. Why do you want to use Git in the way you describe? – CodeCaster May 18 '20 at 07:57
  • 1
    If they're not ready to be committed, to any branch, use stash to put them away. You might also consider creating a secondary working folder so that you can have them uncommitted on disk ready to be committed on some branch. Check out the git worktree command. – Lasse V. Karlsen May 18 '20 at 08:00

1 Answers1

3

Here is one possibility:

# from current master
git add .
git commit -m 'WIP: temporary commit'
git branch temporary
git reset --mixed HEAD~1

For an explanation, the above is first adding all files to the index, and making a commit on master. You ultimately don't want that commit there, but we'll come back to that later. From this point, we branch off a new branch temporary, without actually switching to that branch. Then, from master we do a mixed reset back one commit. This will leave your index empty, with all your original changes in the working directory. Note that the temporary commit is now not part of the master branch, but is the HEAD of the new temporary branch.

Tim Biegeleisen
  • 502,043
  • 27
  • 286
  • 360
  • But now you have a local master branch that is one ahead of origin, meant to be pushed somewhere in the future, _if_ the changes are accepted by someone else. This is a disaster waiting to happen. You might inadvertently push it too soon, or someone else can modify origin/master, so you'll have to merge/pull first. Surely you agree this workflow is bonkers, and that they should incorporate pull requests or a sane merging strategy instead of "pushing a branch for review, then ignoring that branch and committing the same changes on master instead"? – CodeCaster May 18 '20 at 08:07
  • 1
    @CodeCaster I disagree with most of what you said, and you don't understand my answer. In general, most likely just doing something `git stash` is preferable, but I am answering the exact question asked. My answer does _not_ leave the `master` branch one ahead of origin, rather the HEAD of local `master` will still be pointing to the same commit as `origin/master`. Please review your understanding of Git. – Tim Biegeleisen May 18 '20 at 08:09
  • I do understand Git pretty well, thanks. I do agree that, after reading your answer again, I got some stuff wrong in my comment, sorry for the confusion. The gist of it though, is that they're going to let another developer review the "temporary" branch, **and then ignore that branch** and then commit again and push their work to `origin/master` anyway. What is wrong about this, is that what is getting pushed, has no relation whatsoever to what was reviewed. They can omit or add changes to their final `master` commit, which was not in the reviewed work. That part is the part I don't like here. – CodeCaster May 18 '20 at 08:14
  • 1
    @CodeCaster Yes, and I agree with you on those points. But sometimes, we have a need for a non-standard workflow in Git. Yes, it would be ideal to just stick to the `master` branch, or maybe just branch a feature off that. – Tim Biegeleisen May 18 '20 at 08:15