Hello, Matthew. I usually use another alternative
The way you’ve exposed actually solves the case. Branch toggle is allowed, but you end up with an extra commit in the history. I am personally purist about the history of the code and when I do these "dirty" commits, I usually "not ready" to use a rebase or Cherry-pick afterwards to tidy up the house.
There’s a feature in git I like very much called "stash" that fits exactly this scenario: You committed a few minutes ago and continued editing. Ai wants to switch branch and, for this, wants his work files (Working Tree) cleaned.
The stash compares your work files to the last commit you did on the current branch (the famous HEAD), takes the differences, stores it in a drawer and goes back to HEAD, making your Working Tree clean again. At this point branch toggle can follow. Later, you can take what the git stash
saved and reapply over the files. This does not generate a commit and you can get back to work precisely from the point that stopped. It’s like taking something out of the passenger seat to take someone on a ride and then going back to the original seat when the person leaves :D .
Here are some examples:
git stash list
- lists stashs saved in a format similar to
stash@{0}: On master: mais conteudo para o arquivo
stash@{1}: On master: primeiro stash!
being the stash format@{n}: your branch : your message (n is a stash number, 0 pro being the latest.
git stash save "mensagem"
saves the committed versioned files and resets the files to the last commit
git stash apply stash@{1}
apply stash 1, returning the changes that this saved to the files. It can be executed at any time in the future, not necessarily once you return to the branch.
It is a very simple resource and it makes me miss too much in SVN. It allows you to change without heating your head saving patches around.
I hope I’ve helped.
Very good, also I am not in favor of giving commits so "unnecessary", I will definitely start working using
git stash
. Thank you.– MateusFMello