使用 Git 或 Hg，如果整个团队都使用来自中央服务器的拉取和推送，这与 SVN 有什么不同？
假设整个团队使用 Git 或 Mercurial 正在做：
（Mercurial (Hg) 中的示例）：
hg pull
hg update
[edit files or add files, and test]
hg add .
hg commit -m "good"
hg push
我不明白它与使用 SVN 有什么不同？如果团队从不向其他成员推送或拉取，而只是向中央服务器拉取和推送。 （除非我们说合并更好，但合并是 SVN 或 Git/Hg 的工作，只取决于他们做得有多好，而不取决于它是否是 DVCS（分布式版本控制系统））。这是真的吗？
Say, if the whole team using Git or Mercurial is doing:
(example in Mercurial (Hg)):
hg pull
hg update
[edit files or add files, and test]
hg add .
hg commit -m "good"
hg push
I don't see how it is different from using SVN? If the team never push or pull to another member, but just pull and push to a central server. (unless if we say merging is better, but merging is the job of SVN or Git/Hg, just depends how well a job they do it, but not dependent on whether it is a DVCS (Distributed Version Control System)). Is that true?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
一个区别是你不必每次做出承诺时都推动。例如，我经常在一天的编码期间提交几组更改，然后在一天结束时推送一次。
One difference is that you don't have to push every time you commit. For instance I often commit several groups of changes during a day of coding, and then push once at the end of the day.
使用 Subversion，每个人在给定时间在其本地计算机上只有一个存储库修订版本，如果不连接到中央存储库，他们就无法查看修订历史记录或回滚到先前的修订版本。使用 Git 和 Mercurial，每个人都拥有存储库的完整副本，因此可以在本地执行上述所有操作，而无需连接到中央存储库。
Git 和 Mercurial 只需连接到存储库即可推送本地提交并获取本地存储库中尚未的提交。如果没有连接到中央存储库，Subversion 根本无法运行。
With Subversion each person only has a single revision of repository on their local machine at a given time, they cannot view revision history or rollback to a previous revision without connecting to the central repository. With Git and Mercurial, each person has a complete copy of the repository, and thus can do all of the above locally without needing to connect to the central repository.
Git and Mercurial need only connect to the repository to push up locally made commits and fetch commits not yet in the local repository. Subversion cannot function at all without a connection to the central repository.
我认为你的说法大体上是正确的，同时可以有很多不同的答案。
DVCS 为您提供了使用 svn 等中央存储库模型无法实现的可能性：
我确信这一切都取决于您的工作环境以及您可能想要使用的功能。
I think your statement is generally true and at the same time can have a lot of different answers.
The DVCS gives you possibilities that are not possible with a central repository model like svn :
And I am sure much more possibilities. It all depends really the environment you work in and what feature you may want to use.
是的，您可以像集中式一样使用 DVCS，而且您获得的大部分只是速度，但要充分利用 DVCS 需要改变您对版本控制的思考方式。
一个很好的问题是，“如果我可以拥有任意数量的分支，随心所欲地提交，并且只与我想要的人共享这些分支和提交，我会用它做什么？”
举个“你想要多少分店”的例子，我目前有大约 5 个分店适合我。一个是我用于合并以与同事共享的主分支。其中之一是针对我目前正在进行的任务。一个是之前完成的任务，我正在等待同事审核。其中两个是我开始的长期任务，但由于日程优先级而不得不推迟，并将在下一个版本后再次启动。
作为“随心所欲地提交”的好处的一个例子，今天一位同事从静态分析工具中进行了一系列小更改，进行了大约 15 次本地提交，而使用 CVCS 只能完成一次。他不小心引入了一个严重的错误，直到完成后才发现该错误，但通过使用 git bisect 能够快速缩小范围。
作为“正是我想要的人”的示例，请考虑两个开发人员一起开发一项功能。他们需要经常共享，但他们共享的内容通常会破坏主要构建。通过 DVCS，他们只能相互拉取，而无需与所有人共享，然后通过一次凝聚力推动来检查完全正常工作的功能。另一个例子是我不得不推迟的长期任务。如果我的老板决定将该任务交给其他有空的人，我可以轻松地将我部分完成的工作及其所有历史记录交给他。
Yes, you can use DVCS exactly like centralized, and mostly all you will gain is speed, but taking full advantage of DVCS requires a change in the way you think about version control.
A good question to ask is, "If I could have as many branches as I wanted, commit as often as I wanted, and only share those branches and commits with exactly whom I want, what would I do with it?"
As an example of "as many branches as you want," I currently have around 5 branches just for me. One is the master branch I use for merges to share with colleagues. One is for the task I'm currently working on. One is for a previously finished task that I'm waiting for colleagues to review. Two are for longer-term tasks that I started, but had to postpone due to schedule priorities and will pick up again after the next release.
As an example of the benefits of "commit as often as you want," a colleague today made a bunch of small changes from a static analysis tool, making about 15 local commits where only one would be done with CVCS. He accidentally introduced a serious bug that he didn't detect until he was done, but by using
git bisectwas able to quickly narrow it down.As an example of "exactly whom I want," consider two developers working on a feature together. They need to share frequently, but often what they share would break the main build. With DVCS they can pull only from each other without sharing with everyone, and then check in a fully working feature in one cohesive push. Another example is the long-term task I had to postpone. If my boss decides to hand that task to someone else who has freed up, I can easily give him my partially completed work with all its history.
如果你的同事更改了一个文件并提交了更改，那么你在不知道同事的提交的情况下更改了另一个文件，SVN 将允许你的提交，但 Hg 和 git 不会。这是设计使然，因为 hg 和 git 跟踪整个存储库的状态，而 SVN 跟踪单个文件和文件夹的更改。
If your colleague changes one file, and commits the change, then you change another file without knowing about your colleague's commit, SVN will allow your commit, but Hg and git will not. This is by design because hg and git track the state of your entire repository, whereas SVN tracks changes to individual files and folders.