我曾听说，与其在主干中实现一个特性，不如为不同的特性建立单独的分支。
我对这种方法的一个问题是，当合并一个特性到主干时，我们将一次合并整个东西。如果我们这样做，并注释一个文件，以查看不同代码行背后的原因，我们会看到一个注释说"合并xyz特性"，这将不是很有帮助。
有办法克服这个问题吗?
如果您的问题是，当使用SVN Blame(又名Annotate)时，它没有显示您合并修订的所有提交评论列表?
如果是这样，你需要在命令中添加-g标志，或者如果使用TortoiseSVN，请勾选'Include Merge Info'复选框。
有资料这样说，但也有资料说地球是平的。
任务分支在分布式vcs中是可行的，尽管在绝大多数情况下是一种寻找问题的解决方案。在前几代系统中，这将是纯粹的痛苦，没有收获。它不会做任何有用的事情;如果你弄错了，就会造成混乱和不必要的返工。
在最坏的情况下，你的任务分支变成了隐身功能分支。然后你最终要维护数倍于你需要的代码量;每个其他团队成员都有他们自己的私有的代表正在进行的工作的公共库的稍微不同的版本。这意味着每次合并都会破坏一些东西，所以合并发生的次数更少，所以每个分支的分歧更多。
这就是你可能要做的事情，你可能要承担的成本，如果你有多个需求不相容的客户，或者有扭曲的法律限制。除了你对自己的团队这么做，没有任何理由，除了一个模糊的感觉，这是正确的事情。