I'm interacting with Git through GitHub for Windows, which is funny since I'll never push my repository to GitHub. I'm working on it alone and it's intended to be used only by me. I noticed that my commits are listed under "unsynced commits" and under "history" it says "no commits". Which brings me to the question, what will I achieve by pushing except my commits listed under "history"?

  • 14
    There's one significant lack of understanding in the question that's worth pointing out: if you haven't pushed anything remotely, all your work is in the local on-disk repository. Lose your machine, lose everything you ever did. Commented Jul 31, 2012 at 18:03

3 Answers 3


You are technically correct -- no real need to push if you aren't sharing the code with anyone.

Then again, your laptop has a hard drive made by the lowest bidder. Your house could burn down before the hard drive fails. You might want to look at your code remotely. Or even share it with someone.

Now, with Github, they require everything be public or you need to pay for private repositories. So if you want to keep it to yourself, you might want to check out bitbucket which will let you do git but also features free private repos.

Another option would be to save your git repository somewhere that is backed up remotely. But there are few advantages doing this rather than just using a cloud SCM provider these days.

  • BitBucket offers pretty much unlimited number of private repos for free.
    – user11408
    Commented Jul 31, 2012 at 18:02
  • There are plenty of reasons to push. Workflow really doesn't change all that much. You work commit, commit, commit, finish a workflow and push...
    – Rig
    Commented Jul 31, 2012 at 18:12

There is another reason you would like to push to a repo (even if it's, in one way or another, local): workstations.

I don't know about you, but I work in 4 different computers (1 PC at home, 1 Laptop, 1 Office PC and 1 Office Laptop) and pushing changes to a properly set up Git server in my company's server makes syncing fast and painless. Since Git is a DVCS, that's putting that advantage to use: it's not only backups, but all different codebases I'm working on can be easily merged, checked and analyzed.

It can be local if, for example, your home PC is the "server" (or the origin) and you have a home laptop - that way you can easily keep in sync.

Sidenote: People often say "I'd rather use Dropbox (or any other sync service)". The massive amounts of objects that a Git repo has makes it ridiculous to use Dropbox like that. It's an option, but I wouldn't say a good one.

  • +1, I'd definitely do the same in your case. What do you do if you forgot to push at home and are now at work?
    – Zippo
    Commented Jul 31, 2012 at 18:19
  • 2
    @Zippoxer Focus on another task and merge later. Commented Jul 31, 2012 at 18:27
  • Exactly, what @bytebuster said. That's the beauty of the DVCS's! (Although, with enough practice, you won't forget again!)
    – AeroCross
    Commented Jul 31, 2012 at 23:37
  • Alternatively: Work on a side/hobby project to relax or explore new ideas etc. :-)
    – johannes
    Commented Aug 13, 2012 at 22:07

As a distributed SCM, git distinguishes between the concepts 'make a snapshot of the working copy' (commit) and 'sync repositories' (push / pull / fetch).

If you only ever have one local clone of your repository, then it doesn't make sense to push. However, with github, you do have another clone (the one on github), and pushing your changes there has at least one advantage: backup. If your computer dies, you still have everything pushed so far on github.

Of course, that's not github's primary purpose; github is intended for sharing code, so if your project is on github, you can allow others to pull from there, clone your project, act on pull requests from their clones, or even give trusted others push access to your repository.

Another reason to push is if you use several local clones. This can be useful for various things: for example, you may want to work on two different branches at the same time, or you may want to try out possibly destructive operations on your repository; if all works as intended, you keep the modified clone (or push your changes back to the original repo), but if things go south, you can just delete the messed up clone and go back to the original one (which is still unchanged).

Some people even use git for deployment: the production version is also a git repo, and updating to a newer version is a matter of fetch and checkout (obviously, this only works if you don't need a build step). I wouldn't necessarily recommend it for serious stuff, but for small things it is a simple and pragmatic solution.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.