我已经使用 Github 一段时间了，但我对 Git 背后的一些关键概念有点困惑。
我的 VCS 背景从 Source Safe 开始，然后过渡到 SVN 和 TFS。我认为我陷入了 CVS 系统的旧思维方式，如 SVN 和 TFS。
Git 中的服务器端和客户端是什么。据我了解，它们之间没有明显的区别。
从技术意义上来说，分叉意味着什么。它是分支的“类型”吗？
git 中的分支是什么意思？和SVN中的一样吗？
另外，我一直在寻找 Git 核心概念的良好可视化工具，但还没有找到适合我的工具。
I've been using Github for sometime now but I'm getting a bit confused about some key concepts behind Git.
My background with VCS started with Source Safe and then transitioned into SVN and TFS. I think I'm stuck in the old way of thinking of CVS system, like SVN and TFS.
What is considered server-side and client-side in Git. From what I've understood there isn't a clear distinction between them.
In a technical sense, what does a Fork mean. Is it a "type" of branch?
Wat does a branch mean in git? Is it the same as in SVN?
Also I've been looking for a good visualization of the core concepts of Git, but haven't found any one that works for me.
发布评论
评论（5）
以下是理解 Git 的方法：（
从本质上讲，Git 只是一种保存和恢复快照的方法。每个快照都有一个“ID”（SHA1），并且可能有一个或多个指向它的“refs”（指针）。一个分支机构？只是特定快照的更友好的名称。标签？同样的事情。头？这只是当前快照的“代词”。方便的是，这些快照每个都附带了更改内容的描述 - 该描述就是提交消息。
Here's how to understand Git:
At its core, Git is just a way to save and restore snapshots. Each snapshot has an "ID" (the SHA1), and may have one or more "refs" (pointers) to it. A branch? Just a friendlier name for a particular snapshot. Tags? Same thing. HEAD? That's just a "pronoun" for the current snapshot. Conveniently, these snapshots each come with a description of what changed - this description is the commit message.
Git（本地）在项目根目录中有一个目录 (.git/)，您可以在其中提交文件。
Git 是一个DVCS（分布式版本控制系统）使您能够经常保存文件的副本（“版本”），能够合并超过 1 人完成的工作，并且您还可以离线工作。
Git 不同于更传统的 CVS（代码版本控制系统），例如 SVN（Subversion）或 CVS，它们确实有分支，但没有“本地和远程”概念（您的提交直接到远程）。使用 git，您首先提交到本地存储库，然后将这些更改推送到远程。这鼓励更频繁的提交和以更小的块完成工作。它还更好地支持离线工作，因为您可以在离线时提交，然后在下次在线时同步和拉/推。
Git 通过保存整个文件来存储对文件的每个更改。它在这方面与 svn 不同，您可以转到任何单独的版本，而无需通过增量更改“重新创建”它。
Git 不会“锁定”文件，并且需要独占锁定才能进行编辑（我会想到 pvcs 等较旧的系统）。实际上，它在拉取或获取期间将文件更改（在同一文件内！）合并在一起方面做得非常出色。唯一需要进行手动更改的情况是两个更改涉及相同的代码行。
分支
这是当您想要保留主代码、制作副本（分支）然后在该分支中工作时的情况。完成后，将分支合并回主存储库。例如，如果您正在升级到新版本，则可能是这样。
一些商店和个人在单独的分支中完成所有工作，无论是功能、错误修复还是杂务，都有单独的流程和/或指定人员将这些分支合并到主分支中。
因此，使用分支时，您可以管理分支，而使用分叉时，其他人可以控制接受代码。无论如何，这就是标准用法。
Github
github（远程）是一个远程源，如果您拥有（或添加到）这样的存储库，您通常会推送和拉取这些已提交的更改。
所以本地和远程实际上是截然不同的。
当您“分叉”时，即单击 -
，例如在 github 上，您将创建您的 github 帐户中的代码。第一次执行此操作时可能会有点微妙，因此请务必查看代码库列在谁的存储库下 - 要么是原始所有者，要么是“分叉自”和您，例如 
一旦获得本地副本，您就可以根据需要进行更改（通过将其拉取并推送到本地计算机）。完成后，您可以向原始存储库所有者/管理员提交“拉取请求”（听起来很花哨，但实际上您只需单击此：-
) 然后他们将其“拉”进去。
克隆
对于一起处理代码的团队来说，更常见的是“克隆”存储库（单击存储库主屏幕上的“复制”图标）。然后，在本地输入 git clone [paste] 这将在本地进行设置，您可以直接推送和拉取到共享的 github 位置。
可视化
我没有核心概念的可视化，但如果你想看看这些变化是如何运作的，你不能用一个我称之为“地铁地图”的 GUI 来击败可视化工具 gitg (gitx for mac) （尤其是伦敦地铁），非常适合展示谁做了什么、事物如何变化、分歧和合并等。您还可以使用它来提交和管理您的本地更改...
Git (locally) has a directory (.git/) at the project root to which you commit your files.
Git is a DVCS (Distributed Version Control sytem) that enables you to save copies ('versions') of files frequently with the ability to merge work done by more than 1 person and you also have the ability to work offline.
Git differs from more traditional CVS (Code Versioning Systems) like SVN (Subversion) or CVS which do have branches, but no 'local and remote' concept (your commits are directly to the remote). With git you commit to your local repository first and then push those changes to the remote. This encourages more frequent commit and work being done in smaller chunks. It also support off-line work much better as you can commit while offline and then sync and pull/push when next online.
Git stores each change to a file by saving the entire file. It's different from svn in that respect and you can go to any individual version without 'recreating' it through delta changes.
Git doesn't 'lock' files and require exclusive lock for an edit (older systems like pvcs come to mind). It actually does an amazing job of merging file change (within the same file!) together during pulls or fetches. The only time you need to do a manual change is if two changes involve the same line(s) of code.
Branches
This is when you want to preserve the main code, make a copy (branch) and then work within that branch. When you've finished you merge the branch back in to the master repository. One example of this might be if you are working on an upgrade to a new version.
Some shops and individuals do all work, whether its a feature, bug fix or chore, in separate branches, with a separate process and/or designated person to merge these branches into master.
So with a branch you are managing the branch, whereas with a fork someone else controls accepting the code back in. That's the standard usage anyway.
Github
github (a remote) is a remote source that you normally push and pull those committed changes to if you have (or are added to) such a repository.
So local and remote are actually quite distinct.
When you 'fork',, i.e click on -
, say on github, you create a copy of the code in your github account. It can be a little subtle first time you do it, so keep making sure you look at whose repository a code base is listed under - either the original owner or 'forked from' and you, e.g.
Once you have the local copy, you can make changes as you wish (by pulling and pushing them to a local machine). When you are done then you submit a 'pull request' top the original repository owner/admin (sounds fancy but actually you just click on this:-
)and they 'pull' it in.
Cloning
More common for a team working on code together is to 'clone' the repository (click on the 'copy' icon on the repository's main screen). Then, locally type git clone [paste] This will set you up locally and you can push and pull directly to the shared github location.
Visualization
I don't have a visualization of the core concepts, but if you want to see how the changes are working, you can't beat the visual tool gitg (gitx for mac) with a gui that I call 'the subway map' (esp. London Underground), great for showing who did what, how things changes, diverged and merged, etc. You can also use it to commit and manage your local changes...
与基于文件的 CVS 和 SVN 不同，Git 是基于提交的。提交作为提交树存在于存储库中。 git 存储库有 3 个主要部分：工作目录、阶段和存储库目录。
Git 没有中央存储库的绑定概念。存储库的每个克隆都保留其复制的存储库的完整提交历史记录和提交。
分叉只是另一个存储库的克隆或副本。您对存储库副本所做的更改不会影响分叉（克隆）的存储库。要在原始存储库上应用您的更改，您需要“推送”它们或让存储库所有者“拉取”您添加的任何新提交。同样，其他人也分叉你的分叉（即复制你的副本）。而且，对其存储库的任何更改都不会影响您的存储库，除非您将这些更改拉入。Git
是一个了不起的工具。它不仅可以作为版本控制工作的一种方式，而且还使协作和实验变得更加容易。还有更多。
我强烈推荐 ProGit Book 来帮助您更好地了解 Git 的原理和内容。
Unlike CVS and SVN which are file based, Git is commit based. The commits live in the repository as a tree of commits. There are 3 main sections to a git repository, the working directory the stage and the repository directory.
Git has no binding concept of a central repository. Every clone of a repository holds the full history of commit and commits of the repository it copied.
A fork is merely a clone or copy of another repository. The changes you make on your copy of the repository will not affect the repository that was forked (clone). To apply your changes on the original repository you would need to 'push' them or have the repository owner 'pull' any new commits you have added. Likewise others fork your fork (i.e. make a copy of your copy). And, any changes to their repository will not affect your repository unless you pull those changes in.
Git is an amazing tool. It serves not just as a way to version control work, but also makes collaboration and experimentation a lot easier. And there is so much more too it.
I highly recommend ProGit Book to help you get more acquainted with how and what Git is about.
Scott Chacon 有一篇关于 Git 内部结构的精彩演讲。
带旁白的幻灯片： http://blip.tv/scott-chacon/git-talk- 4113729
再次幻灯片：http://www.slideshare.net/chacon/getting-git
演讲现场录音：http://vimeo.com/1099027
There is a nice talk about the internals of Git by Scott Chacon.
A slideshow with voiceover: http://blip.tv/scott-chacon/git-talk-4113729
The slides again: http://www.slideshare.net/chacon/getting-git
A live recording of the talk: http://vimeo.com/1099027
Git For Ages 4 And Up 是关于 Git 的有趣演讲，并使用 可视化 href="http://www.hasbro.com/playskool/en_US/shop/browse/Playskool/Tinkertoy/_/N-1rZ78Z7nZgt/Ne-2l" rel="nofollow">Tinkertoys。
Git For Ages 4 And Up is a fun talk on Git and provides surprisingly useful visualizations using Tinkertoys.