版本控制系统中源代码的本地副本

Question

在使用版本控制系统时，每个协作者都在其本地计算机上拥有代码库的本地副本。

1. 如果版本控制崩溃，可以通过协作者副本的代码库恢复VCS吗？如果是的话，Git在这方面与VCS有何不同。

2. 当协作者从VCS更新源代码时，他是否只会将补丁更改修补到现有文件，否则他将获得文件的新版本。请教育我Git在这方面与VCS的不同之处。

3. 我做的另一个观察是，如果有很多开发人员正在开发VCS上的软件项目，并且假设两个开发人员Jack和Tim正在开发一个共同的功能并处理同一个文件。在VCS中，如果蒂姆希望杰克的更改能够让他继续工作，那么杰克就不得不提交他的代码。如果Jacks代码有一些错误，其他协作者无法更新其代码库。因此，杰克被迫通过适当的测试检查他的更新，之后蒂姆才能完成他的改变。这是一个瓶颈，而在Git的情况下，Jack和Tim可以在Jack的存储库中创建的功能分支上一起工作，Tim可以指向Jack的存储库并从Jack的存储库中获取常见功能..一旦功能完成，杰克可以将他和蒂姆的更改合并到主分支。

我的理解是否正确。如果我遗漏了上述情况中的任何其他要点，请更新。

为了便于比较，我们将SVN作为我们的VCS

此致 普拉迪普

Answer 1

我不是VCS的专家，我只熟悉cvs，svn和git，所以其他人应该添加更正......

回答你的观点：

1. 作为一个分布式VCS，Git可以直接重建服务器存储库，只需克隆它，就像用户可以从服务器存储库中克隆一样。这是因为任何用户的存储库都可以与服务器存储库一样完整（如果是最新的）。对于大多数其他VCS，情况并非如此（除了git之外，我自己不知道任何其他分布式VCS）。

实际上，尝试从用户的本地副本（使用除git之外的大多数VCS）还原服务器只能恢复代码库的当前状态，而不是其历史记录。另一方面，使用Git，整个历史记录将从用户存储库中恢复。

1. 用户仅获取与其本地存储库中可用的上一次父提交相关的增量更改。这也是我所知道的其他VCS中的典型行为（cvs，svn）。

2. 通常在提交时没有检查代码验证（例如代码编译好），因此Jack原则上可以随时检查他的（损坏的）代码，以使其立即可供Tim使用。但是，这可能对其他相关人员有害，并且不被视为良好做法，并且明确不鼓励公司政策，编码指南和其他此类指导方针。

作为替代方案，Jack可以将他的代码签入开发分支，以最大限度地减少对主分支的干扰。