Understanding git – why even commit locally?

I know the difference between commit vs push (local vs remote repo)

I come from a SubVersion background: Why even have the option to commit “locally”? What is the point of that? Wouldn’t it make sense to just always commit to the remote repository?

  • Bitbucket: Update a fork to merge changes of master repo?
  • Merges between two branches in two directions - any good reason or completely forbid?
  • SVN & DVCS workflow - preserving history
  • What is the Fork & Pull Model in GitHub?
  • Is Subversion better at cherry-picking then git (or any DAG VCS)?
  • Change threshold on the similarity index for git merge with renaming involved (like -M --find-renames on diff)
  • I don’t understand why we have this intermediate local repository?

  • How to update an Heroku App created using github “Deploy to Heroku” button?
  • Git submodule head 'reference is not a tree' error
  • Git - Clone Repositories in Bulk
  • Version controlling Android/Eclipse project with all it's 3rd party libraries
  • Version control using git with Dymola/Modelica
  • Git: how to find out real changed files in a merge commit?
  • 3 Solutions collect form web for “Understanding git – why even commit locally?”

    From the wikipedia:

    DVCS proponents point to several advantages of distributed version control systems over the traditional centralised model:

    • Allows users to work productively when not connected to a network.
    • Makes most operations much faster.
    • Allows participation in projects without requiring permissions from project authorities, and thus arguably better fosters culture of meritocracy instead of requiring “committer” status.
    • Allows private work, so users can use their changes even for early drafts they do not want to publish.
    • Avoids relying on one physical machine as a single point of failure.
    • Permits centralized control of the “release version” of the project
    • On FLOSS software projects it is much easier to create a project fork from a project that is stalled because of leadership conflicts or design disagreements.

    This is the main idea of DVCS: your local folder is a full-potential repository too. You don’t even need a remote to use Git.

    As AD7six comments: Wouldn't it make sense to just always commit to the remote repository? – that’s not possible with git.

    Moreover, it allows you to fix any mistakes you’ve done in a commit. You can change your commit, add to it, reject it and make another one. All your possible mistakes and attempts will never go to the common repository, will not be seen by anybody and will not interfere in the work of other people.

    From the Pro Git book:

    In a DVCS (such as Git, Mercurial, Bazaar or Darcs), clients don’t just check out the latest snapshot of the files: they fully mirror the repository. Thus if any server dies, and these systems were collaborating via it, any of the client repositories can be copied back up to the server to restore it. Every clone is really a full backup of all the data.

    enter image description here

    Git follows the model of DVCS (Distributed Version Control System) so you can commit changes even if you don’t have access to the remote repo e.g. you’re on a trip and you can still commit to the local repo since the entire copy of repository is on your disk (the .git directory), so you can work as if you had access to the remote repo.
    Once you can connect to your remote repo, you can push the changes you’ve done from your local repo.

    Git Baby is a git and github fan, let's start git clone.