团队中的开发人员是否有过“个人”版本控制？

Question

我认为，过了一段时间，许多开发人员都会了解/喜欢一个特定的VCS。如果您发现自己在一个团队中使用了一个不兼容的系统--您是学习新系统并根据团队的工作流程调整工作流程，还是保留旧系统，并试图使两者协同工作呢？我觉得这不是一种非常普遍的策略，就是一种严重的失礼。

我对软件开发还不熟悉，所以到目前为止，这个问题对我来说完全是假设性的。虽然我的直觉告诉我，git/Mercurial的分散结构和分支性质会比我的团队所用的非常集中的Vault更吸引我，但我对与版本控制的工作还不太了解，所以在可预见的将来，我将坚持团队运行的任何系统。

但这确实让我想知道，对于面临学习新VCS的开发人员来说，推出两种系统的“混合体”有多普遍--在本地使用他们喜欢的系统来管理他们正在做的事情，而且实际上只使用团队范围的系统来提交/更新。当然，这会引发其他问题--同时使用两个系统是否有固定的模式？您如何处理本地回购无法访问整个项目历史的事实？等等..。

Answer 1

简单地说，这取决于所讨论的版本控制系统、您在团队中的角色以及公司的政策。

有些公司对你可以使用的东西有非常严格的政策，你可能会被公司标准的任何版本控制软件困住。在其他地方，您会发现开发人员有更多的灵活性，因此如果您选择的工具可以与标准版本控制系统很好地互操作，那么您可以使用它。

重要的是，如果您使用DVCS保存本地存储库，然后将代码拖/推送到集中式版本控制系统中，则需要确保您仍然定期提交(记住“定期”提交，因为svn之类的代码仍然不像git那样频繁，但是要确保您经常提交代码--可能是每天提交，至少每周一次)。您不希望在本地存储库中囤积大量的更改，然后突然进行大量提交。

如果您认为您喜欢的VCS确实比您目前正在使用的任何东西更适合团队的需求，那么可以随意提及它，并推动(轻轻)团队进行更改。如果您在新版本开始之前或在新项目开始时推动它，这将是最成功的。如果团队在发布周期中处于半程，那么除了直接提及您喜欢不同的VCS之外，任何事情都可能会激怒您的团队成员，因为在项目中期切换版本控制系统是一个非常糟糕的主意，不管您当时使用的是什么VCS。

从我个人的经验来看，在我开始之前的工作场所，一切都是以颠覆为基础的。由于我被雇来启动一个新项目，我提到我喜欢git，并建议我们利用这个新项目作为试点，看看git是否适合公司的其他成员。我花了很多时间指导其他团队成员如何使用git，并逐渐使他们跟上进度。同时，当我需要处理一些仍然处于颠覆状态的旧项目时，我只是使用了svn，并没有大惊小怪。当项目完成时，每个人都有机会看到使用DVCS的好处，没有人反对我使用git-svn与旧的代码库交互。

如果我一开始就坚持每个人都应该切换到git，或者坚持在本地使用git，并且抱怨必须与svn交互，那么我可能就没有那么成功了，因为它不太像“嘿，这是一件很好的事情”，而更像是“我不太喜欢你，因为你做了一个错误的选择来使用那个工具”。

Answer 2

当然，使用新一代DVCS与任何其他源代码控制系统都是可能的。必要的时候我会和吉特一起做的。

在使用Subversion时，Git提供了内置的客户端支持，效果非常好。

我有机会和其他源代码控制系统一起使用Git。您可以在任何地方创建Git存储库，因此在其他源代码管理系统的工作目录中创建一个。我所做的是有一个分支来反映外部源代码控制系统的确切状态--调用任何东西，但是master工作得很好。在其他分支做你自己的开发。

要将您的更改提交回上游，首先切换到master分支并获取最新的上游更改，将其提交给master。然后从您的开发分支合并您的更改。希望您使用的源代码管理系统不要求您在更改每个文件之前对其进行具体标记，但如果需要(例如Perforce)，则必须手动进行。(在Perforce的具体例子中，已经有git p4这样做了，但在一般情况下不会预先编写。)

将您的开发合并到master中之后，就像通常一样，将这些更改提交到外部源代码控制系统。

使用git svn和git p4 (我敢肯定)，这些连接器为您完成了以下部分或全部工作：

• 将远程系统中的提交映射到Git中的提交(因此您得到了所有相同的提交消息等等)
• 自动签出编辑文件(如p4 edit)
• 将更改提交回外部源代码管理系统。

我通常建议以上程序只适用于那些精通Git (或任何DVCS的选择)。

Answer 3

这将取决于情况和有多少颠覆是可以容忍的。

在大多数情况下，最好使用团队决定使用的内容。但是有一个警告--如果团队选择了一个可靠的版本控制系统(阅读Git，Mercurial，Subversion等等)那么，你应该不会有一个问题，使用一个由团队选择代替你自己的。为了合作，人们必须尝试抛开个人的好恶。

然而，有些时候，我不得不与糟糕的修订控制系统和实践做斗争。曾否尝试使用VSS6.0(2008年)？通过一个本土的基于web的用户界面(接受单一文件提交每一个5分钟)？这应该是一个自己的故事，但当我将存储库复制到Subversion上并将更改提交回时，我发现自己的效率要高得多，而不破坏构建。我要强调的最后一部分，因为这将不是一件容易的事情，转移指责你不是一个团队的球员；确保构建不会中断将增加一点可靠性在你的提交。