There is a minimum level of knowledge you need to know to use git. It is not as straightforward as, say a simple text editor. The problem git is solving is more complex than that, and therefore understanding how to use it requires investing a significant amount of time in learning how it works.
If I was going to go back to my previous commit, I would use "git reset" to go back to the commit prior to the one I just committed. The only reason to use "git reflog" as part of that process is to see which commit was prior to the one you are working with now (in order to pass it to "git reset" to undo the changes).
> "Undo" is a reasonable choice if you barely understand what git is for and "reflog" is not.
But "git reflog" is not an undo mechanism. It can be used to determine a commit SHA to reset to (in order to 'undo' the last commit with "git reset"), but it is used for a bunch of other things also. It is appropriately named for what it does.
If you "barely understand what git is for" then the solution is to learn the minimum you need about git in order to use it effectively. I am not talking about mastering git, that's an entirely different topic. I'm talking about basic-level knowledge. Again, the required initial time investment for git is significant, but in my opinion it is worth it.
If you don't feel the investment is worth it, then you should use something else.
No. You are being deliberately obtuse. There is no way to argue that "reflog" is something that is intuitive or that should be known by somebody who just wants to commit on branches and merge them sometimes. Which is what most people need git for.
If the minimum level of knowledge to operate a car is to know what every piece of it does and how to reassemble it from scratch the designer of said car hasn't been doing his job.
This is exactly the problem with git. You wanted 2 branches and now you have to understand the that the underlying system is actually a filesystem cause that's what Torvalds was used to.
Also, if you don't want to use "git reflog" at all for "undoing", you could undo your previous commit with:
git reset HEAD^
Or if you also want to discard the changes you made to files in the repo at the same time:
git reset HEAD^ --hard
But use the --hard option wisely. Be sure you really don't want to keep any of the changes you made (or that you have already saved them elsewhere before running it).
There is a minimum level of knowledge you need to know to use git. It is not as straightforward as, say a simple text editor. The problem git is solving is more complex than that, and therefore understanding how to use it requires investing a significant amount of time in learning how it works.
If I was going to go back to my previous commit, I would use "git reset" to go back to the commit prior to the one I just committed. The only reason to use "git reflog" as part of that process is to see which commit was prior to the one you are working with now (in order to pass it to "git reset" to undo the changes).
> "Undo" is a reasonable choice if you barely understand what git is for and "reflog" is not.
But "git reflog" is not an undo mechanism. It can be used to determine a commit SHA to reset to (in order to 'undo' the last commit with "git reset"), but it is used for a bunch of other things also. It is appropriately named for what it does.
If you "barely understand what git is for" then the solution is to learn the minimum you need about git in order to use it effectively. I am not talking about mastering git, that's an entirely different topic. I'm talking about basic-level knowledge. Again, the required initial time investment for git is significant, but in my opinion it is worth it.
If you don't feel the investment is worth it, then you should use something else.