I am starting to learn Git. I've been messing around with GitKraken, and I hope that using a GUI is a viable path for saving and sharing stuff. I prefer GUIs to the command line.
Now I understand, in the GUI, I need to stage files, then commit them and then push, to upload them. But why are push and commit two different things? Why would want to just commit locally, without the following upload to keep files synced?
A couple of (concrete) reasons. TLDR in bold.
The first reason is you might not be able to push to the remote, because you aren't connected to the internet.
The second reason is that sometimes commits aren't ready to be pushed. For example, I practice TDD. After I commit a failing test (which I do), I don't want to push that to the remote, because then my team may pull in a failing test suite. Another common practice is to squash these commits before pushing them out so it looks like the feature was one single commit.
Third reason is that it's a personal project that you don't want to share with anyone, and so there is no remote to push to at all. You don't have to have a remote with a git repo.
Fourth reason is you may have multiple remotes (in general, distributed semantics get in the way). So after you commit, how would git know which remote you want to push to? All of them? A certain one? A certain two out of the seven? Pushing must be explicit from git's perspective due to the semantics of git being a distributed VCS. See poke's answer for more detail.
P.S. This is off topic to the question, but the command line shells (including bash) are extremely powerful interfaces once you learn to use them. After you become proficient with these tools, using them is much faster than any GUI you're going to find. This has to do with the fact that you can do powerful actions with keystrokes instead of the mouse, and that it's infinitely customizable to fit your needs.
Git is a distributed version control system. As such, there is no single central repository, like with Subversion or even CVS. So if there was a single command to commit and push, then where would that commit would go? What would be the remote repository?
In Git, there is no central repository. There is not even any hierarchy in repositories. For a local repository, any other repository is a remote repository it can interact with. And the local repository is just a possible remote repository for any other repository.
So local and remote are just points of view relative to your current location: The local repository is always the current repository, and every other repository is a remote that you can interact with.
When working with Git, your local repository is what you interact with: You commit all your changes locally. This has many benefits and use cases that I won’t go into detail here, but essentially it is what makes version control distributed, as the local repository has all the information, the full history.
So when you have that local repository, which has the full history and all the changes, you need a way to interact with other repositories, in order to allow you to share the history. The two ways to do that are push and pull (or fetch). Since with distributed repositories, every repository is the same, every repository can push or pull from another (assuming they have access).
In the end, committing and pushing is required to be separate steps because one is interacting with the (local) repository while the other is a deliberate step to share changes with a remote repository.
In the old days (like five years ago--ancient history by today's standards of memory) people were sometimes not connected to the internet! And they wanted to continue working! So they just committed as they worked. When connection was achieved, they'd go ahead and push all their commits. Git was designed with this as the primary paradigm.
Flash-forward all those eras to the present and lo, the mechanics of versioning our software hasn't changed (much).
Some people have argued that you keep all your commits local until you're satisfied that your code is robust. I admire their instincts: protect the main repository code; keep it as flawless as possible. Yes, of course, please do!
But Git provides a mechanism that works much better for not-so-perfect-code, it's called branches. Make a branch, work on it (pushing commits all along) until satisfied, then merge that branch to the main. This way if something happens to your computer (hard drive crash, coffee spill, theft, etc.) all your work is still backed up. That's one of the points of version control, right?
Yet others have argued that in a highly distributed development system, one needs to specify where and how to push commits. This is certainly an option, but I have yet to see this in practice. I can't imagine a company saying to its developers, "Go out there and each of you keep your own copy of the code. We'll let you push and pull from each other as you feel and hope that nothing goes wrong or gets confusing." Yeah. So much easier to setup a bitbucket or github account and tell everyone: "Use this as your origin!"
So to be blunt: just push with every commit. There is no downside to do this, and there's some small chance of losing work if you don't.
They serve different purposes. Each commit should change one isolated aspect of the code; for example, rename a variable, replace calls to one function with calls to another, or even just fix a typo in a comment. Think of them as rollback points; if I change my mind about the approach I took here, can I drop a small set of commits and still keep these other, unrelated changes?
A push should only happen when your series of commits reaches a new stable point in development which has been tested enough to be shared with your colleagues or collaborators.
It's not impossible or unusual to make one push for each commit if you are working e.g. on fixing minor bugs. But a lot of the time, it makes sense to commit individual changes as you proceed towards a larger goal, and only push when you think you have reached that goal.
