不同的版本控制工具是否更适合不同的语言？
我想知道，是否有哪些特定语言（C++、Java、Python、Haskell 等）比其他语言更适合一种 VCS？也许是由于语法或其他因素？
或者选择 VCS 是否应该始终不受此类问题的影响？
I was wondering, are there any ways in which specific languages (C++, Java, Python, Haskell, etc) are especially suited more to one VCS than others? Maybe due to syntax or other factors?
Or should choosing a VCS always be unaffected by such concerns?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我所知道的所有 VCS 都与内容无关，您可以存储二进制或文本 (ASCII/UTF-8) 文件。选择 VCS 的一个可能因素是开发操作系统支持（例如：git 对 Windows 的支持很差）和 IDE 集成，这可能是特定于语言的。
至于VCS是否应该不受这些担忧的影响，我确实这么认为。同时它应该足够灵活，可以让其他工具执行语言和项目特定的操作（大多数 VCS 通过钩子来完成此操作）。
All VCS' I know are content agnostic, you can store binary or text (ASCII/UTF-8) files. One possible factor for choosing a VCS is development OS support (example: git has bad windows support) and IDE integration, which may be language-specific.
As to whether a VCS should be unaffected by such concerns, I truly believe so. At the same time it should be flexible enough to let other tools do language and project specific things (most VCS do this through hooks).
您放入 VCS 中的内容可能会影响以下方面：
存储：对于简单文本、Microsoft Word 文档、UML 模型（Rational
.rose文件）、html 页面，增量的存储方式可能有所不同, ...例如，请参阅 ClearCase 类型管理器 作为 VCS 基于元素内容管理存储的示例。
合并：可以根据版本化文件的内容通过以下方式进行不同的合并：
关于您的问题，据我所知，版本化文件中的编程语言从来都不是存储或合并的标准：它们（文件）只是文本。
如果对它们进行不同的处理，则只有在合并过程中，并且只有外部合并工具足够智能，可以根据文件内容执行某种“智能”合并时。
但 VCS 本身通常不参与该特殊合并（对于被视为文本的源文件）。
The content you put in a VCS can matter for:
storage: the way the delta is stored can differ for simple texts, Microsoft Word documents, UML models (Rational
.rosefiles), html pages, ...See for instance ClearCase type manager as an example of VCS managing the storage based on element content.
merge: merging can be done differently based on the content of the versioned files through:
Regarding your question, the programing language within versioned files is to my knowledge never a criteria for storing or merging: they (the files) are just text.
If they are treated differently, it would be only during the merge process, and only if an external merge tool is smart enough to perform an "intelligent" merge of some kind based on the file content.
But the VCS itself is generally not involved in that special merge (for source files considered as text).
对于 VCS 而言，您放入其中的内容并不重要（您甚至可能没有代码），但您使用它的方式却很重要。大多数 IDE 可以与部分版本控制系统集成，但不是所有版本控制系统。选择一个您的 IDE 可以集成（本地或通过插件）的 VCS 将带来显着的好处。
话虽如此，如果要在没有 IDE 支持的 VCS 或根本没有 VCS 之间进行选择，请始终使用 VCS。
It doesnt matter to the VCS what you put in it, (you might not even have code in it) but the way you use it does. Most IDEs can integrate with some, but not all version control systems. Picking a VCS your IDE can integrate (either nativly or with plugins) with will provide provide a significant benefit.
With that said, if the choice is between a VCS with no IDE support or no VCS at all, always ALWAYS use VCS.
往往会导致源文件的平均大小不同。某些语言和编码风格往往会导致 10000 行以上的代码文件。在这种情况下，您绝对需要一个基于合并的分支工具。对于较小的代码文件，其他人在同一文件中进行不相关更改的可能性要小得多，因此主要通过锁定工作、仅偶尔进行合并的工具/策略效果很好。
The thing that tends to make a differences average size of source file. Some lanuages and coding styles tend to lead to 10000+ line code files. In that case, you absolutely need a merge-based, branching tool. With smaller code files, there is much less chance someone else will be making an unrelated change in the same file, and so a tool/policy that works mostly by locking, with only occasional merges, works well.