EmphasizedInsanity at /life

Distributed Nature

Git was designed from the ground up as a distributed version control system.

In a distributed version control software like Git every user has a complete copy of the repository data stored locally (a.k.a a local working copy), thereby making access to file history extremely fast, as well as allowing full functionality and access when disconnected from the network. It also means every user has a complete backup of the repository. If any repository is lost due to system failure only the changes which were unique to that repository are lost. If users frequently push and fetch changes with each other this tends to be an incredibly small amount of loss, if any at all.

In a centralized VCS like Subversion only the central repository has the complete history. This means that users must communicate over the network with the central repository to obtain older versions for a file, Backups must be maintained independently and if the central repository is lost due to system failure it must be restored from backup and all changes since that last backup are likely to be lost. (Depending on the backup policies).

Access Control

Due to being distributed, you inherently do not have to give commit access to other people. Instead, you decide when to merge what from whom.

Branch Handling

Branches in Git are a core concept used everyday by every user. In Subversion they are almost an afterthought and tend to be avoided unless absolutely necessary.

The reason branches are so core in Git is every developer’s working directory is itself a branch. Even if two developers are modifying two different unrelated files at the same time it’s easy to view these two different working directories as different branches stemming from the same common base revision of the project.

So than Git:

• Automatically tracks the project revision the branch started from.
  • Knowing the starting point of a branch is necessary in order to successfully merge the branch back to the main trunk that it came from.
• Automatically records branch merge events.
  • Merge records always include the following details:
  • Who performed the merge.
  • What branch(es) and revision(s) were merged.
    • All changes made on the branch(es) remain attributed to the original authors and the original timestamps of those changes.
  • What additional changes were made to complete the merge successfully.
    • Any changes made during the merge that is beyond those made on the branch(es) being merged is attributed to the user performing the merge.
  • When the merge was done

  • Why the merge was done (optional; can be supplied by the user).

• Automatically starts the next merge at the last merge.
  • Knowing what revision was last merged is necessary in order to successfully merge the same branches together again in the future.

Performance

Git is extremely fast. Since all operations (except for push and fetch) are local there is no network latency involved to:

• Perform a diff.
• View file history.
• Commit changes.
• Merge branches.
• Obtain any other revision of a file (not just the prior committed revision).
• Switch branches.

Space Requirements

Git’s repository and working directory sizes are extremely small when compared to SVN.