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?

  • Migration from StarTeam to distributed source control
  • Is there any distributed revision control system that supports partial checkout/clone?
  • Converting Git workflow to Mercurial
  • How would you store encrypted information in public DVCS repository?
  • Mercurial linear history using hg rebase with uncommited changes
  • TFS Shelve vs DVCS (e.g Git, Mercurial) offline commits
  • I don’t understand why we have this intermediate local repository?

  • No submodule mapping found in .gitmodule for a path that's not a submodule
  • Working with multiple programmers on MS Access
  • How to suppress confirmation “Launch '$difftool' :” iff (if and only if) a specific file is passed to git difftool?
  • git rebase mixes commits
  • Github Repo - 'fatal: Could not read from remote repository.'
  • How to remove previously added git subtree and its history
  • 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.