How Git Is Different

There are generally two models in version control systems: centralized and

distributed.Tools such as Subversion typically require a network connection

to a centralized server.You make a change to your project and then commit

that change, which is sent to the centralized server to track. Other developers

can then immediately access your changes.

Distributed version control systems, such as Git, break the process of committing

code and sharing it with others into two parts.You can commit your

code to your local private repository without having to talk to a centralized

server, removing the need to be connected to a network to make a change.

Private vs. Public Repositories

Each developer who is sharing code with other developers has at least two

repositories: a private and a public repository. The private repository is the

one that exists on your computer and is the one you make commits to.

Public repositories are the repository that you use to share your changes with

other developers. Multiple developers might have access to push changes to

the same public repository, or each developer may have their own public

repositories.

You can push to and fetch from multiple repositories. This allows you to pull

in changes from another developer who’s working on the same project.THE GITWORKFLOW 13

Commit IDs Instead of Revision Numbers

Centralized VCS have the benefit of having one system that doles out revision

numbers. Because everyone is committing and sharing their code in one

repository, that repository can control what numbers it assigns to a particular

commit.

That model doesn’t work in a decentralized system.Who’s to say which commit

is actually the second commit, me or you? Git uses commit IDs that are

SHA-1 hashes instead. The hash is based on the code, what came before it,

who made the commit, when they made it, and a few other pieces of metadata.

The chances are incredibly small of there being two different commits with

the same commit ID.

Forking Is Good

For the longest time, forking a project was a bad thing. It drained resources

away from the main project, and merging changes between the two projects

was time-consuming when possible.

Git’s superior merge capabilities, rooted in its distributed nature, make merging

changes from a “forked” repository trivial. In fact, the idea of forking is

so ingrained in the Git community that one of the largest Git communities

online, GitHub,2 is built around the concept.To offer your changes, you fork

a repository, commit your changes, and then ask the original developer to pull

your changes in through a pull request.

Instead of an indicator of a project suffering from internal strife, the number

of forks on a repository is considered the sign of an active community

working on a project.

翻译草稿：

Git有何不同

它与传统的集中化管理的版本控制系统不同。如果你之前是什么集中化管理的版本控制，本节将解释有何不同，希望使得你能掌握GIT的思维方式。

分布式VS.集中化

版本控制系统通常分为两种模型：集中化与分布式，如SVN这样的工具，使用集中化管理模型，本地修改以后，需要通过网络连接到一个中心服务器，提交到服务器，由服务端记录这些提交记录，然后其它开发者就能立即获取到修改内容。

分布式模型，如GIT，会将提交代码与分享代码这个过程分为两个不同的部分，开发者可以提交修改到本地私有的库里并不告诉中心库这些提交，不需要连接网络来完成一次修改提交。

私有库VS.公有库

每位开发者至少与两个库交互：一个私有，一个公有。私有库是存在于本地，并且是往它上面开发提交，公有库是用来与其它开发者共享变化。公有库可以是多个开发使用一个，供多个开发者来推他们的变化到库上来，而每个开发者也可以有他们自己的公有库。（这怎么共享变化呢？）

开发者可以从与多个库交互，对于工作在同一个项目上的开发者们，可以互相获取其它人的提交内容。

用提交ID替代版本号

集中化版本控制系统的关键点就是一个系统负责产生版本号，统一管理下，对每次提交都产生一个新的版本号，而且是支持同步操作的。

对于不集中化管理的系统就不能使用上面的模型了，因为没有谁能记录清哪个先提交，哪个后提交。GIT使用提交ID的概念，提交Id一个使用SHA-1哈希生成的串。哈希是基于代码的源数据：修改前信息，提交者，提交时间，等数据。保证了不同的提交生成的ID绝对唯一。

分支有好处

很长时间里，项目分支被认为是坏事，因为它分走资源，并且合并时将非常耗时。

GIT具有合并的优秀特性，这根植于它做为分布式的特性中，它能合并变化从分支库中。

实际上，分支的注意是如此的根深蒂固，以至于有一个大的在线社区－GITHUB，就是围绕着这个概念而成立的。你若想做一些修改，可以拉一个分支，然后提交修改，再告诉原来的作者去拉你的修改通过一个拉请求。

这样使用得分支不再做为一个项目很混乱的指标，相反相当数量的分支基于一个库会被认为这个项目是由一个活跃的社团来工作。