版本控制约定和最佳实践

Question

我目前在我的项目中使用SVN（虽然我很快会尝试git）并且我知道大部分基础知识（提交，更新，分支，合并等）虽然我觉得我仍然有点无知如何正确使用它。顺便说一句，我的项目目前只涉及我自己。

下面是一个示例场景：我们有SVN服务器，实时Web服务器，开发/测试Web服务器和我的工作站。我创建了一个涉及多个新文件的新功能，并使用消息“创建新功能X”提交它，一旦在开发服务器上检出我经历了看到错误的循环，修复错误，提交，签出，重复直到所有错误都消失了。其中一些错误修复可能是简单的错别字。

所以我有点困惑，因为主要功能提交似乎与微小的错误修复提交“相提并论”（如果这是有道理的），当我看到版本列表时我可能只是想看到主要的变化而不是小修复。此外，“有意义的提交消息”可能需要花费10倍的时间才能输出实际的错误修复，因此更常见的是我不会将其留空或输入“er”。这似乎不太正确。那我错过了什么？或者我只是懒惰？

Answer 1

在所有版本控制系统中，提交/修订都是相同的，并且根据更改的大小不重要。这就是分支和标记的结果。标记a＆＃34;功能完整＆＃34;自上一个标记/分支以来的提交集，并在测试/ Web服务器上进行处理。 （另外，我可以建议自动化测试和持续集成。）

有意义的提交消息是版本控制的一部分。无论您的更改有多小，请尝试使消息有意义。我的许多开发团队，提交消息被固定为固定格式并具有一些必要的信息，如错误跟踪器编号等。即使对于只有一个人的小项目，现在，提供适当的消息总是好的。在Git中，您可以根据需要轻松编辑提交消息，稍后再推送到中央存储库。通过这种方式，您可以提交较小的消息（请注意，我并不是说小消息不一定有意义），而是在提交时花费一些时间进行微调＆＃34;你的历史。

Answer 2

关于最佳做法的出奇的好书是Practical Perforce。这是一本关于专有版本控制系统Perforce的书，但本书继续解释使用Perforce的最佳方式，最终成为使用几乎任何版本控制系统的最佳方式。

我已经从本书中学到了很多我应用于其他版本控制系统的最佳实践，并且我已经推荐给其他人 - 即使他们从未计划使用Perforce - 只是因为它有一些优秀的最佳实践想法。其中包括：

• 不要使用基于环境的分支（即特殊的UAT分支，因为开发中的内容最终会以UAT结尾）。
• 需要时分支，而不是之前分支。这主要意味着您在发布代码完成时分支发布版本，并且不在发布版本中的新内容将被放入代码中。
• 释放树枝而不是树干。这将允许您在仍在处理下一个版本时执行修补程序。
• 不要尝试挑选修复程序。它永远不会按预期工作。将始终存在代码更改，这取决于另一个代码更改，这取决于您不想发布的另一个代码更改。
• 使用可以进行自动化测试并根据每次变化进行构建的持续集成系统。

我知道当你想要使用另一个版本控制系统时，阅读一本关于一个版本控制系统的书似乎很奇怪，但是大多数版本控制书都是关于软件的细节而不是使用该软件的最佳实践。这是涵盖两者的少数几本书之一，其中大部分也可以应用于其他版本控制系统。