如果版本控制关键字被禁止，如何防止文件混淆？
至少有两位杰出的程序员，Linus Torvalds 和 Guido von Rossum，鄙视将关键字放入扩展以显示版本号、最后作者等的文件中的做法。
我知道关键字差异如何使差异变得混乱。 我喜欢 SlickEdit 的 DiffZilla 的原因之一是它可以设置为跳过主要评论。
然而，我对团队编程有着清晰的记忆，其中我们有一个文件的四个版本（两个不同的版本、一个客户一次性版本和开发版本），所有版本都同时打开以进行修补，并且对于验证非常有帮助乍一看，每次我们导航到包含的标头时，我们都会得到正确的标头，并且每次粘贴代码时，源和目标都是我们所期望的。
当仓促的开发人员使用文件系统将文件从一个地方复制到另一个地方，而不是使用该工具将其从存储库中检出时，还会出现这个文件来自哪里的问题； 或者，更可靠的是，当位置 A、B 和 C 中受控制的文件需要编组（通过挑选）到分发位置 D 时。
在 VCS 关键字被禁止的地方，您如何应对？
At least two brilliant programmers, Linus Torvalds and Guido von Rossum, disparage the practice of putting keywords into a file that expand to show the version number, last author, etc.
I know how keyword differences clutter up diffs. One of the reasons I like SlickEdit's DiffZilla is because it can be set to skip leading comments.
However, I have vivid memories of team-programming where we had four versions of a file (two different releases, a customer one-off, and the development version) all open for patching at the same time, and was quite helpful to verify with a glance that each time we navigated to an included header we got the proper one, and each time we pasted code the source and destination were what we expected.
There is also the where-did-this-file-come-from problem that arises when a hasty developer copies a file from one place to another using the file system, rather than checking it out of the repository using the tool; or, more defensibly, when files under control in locations A, B, and C need to be marshalled (with cherry-picking) into a distribution location D.
In places where VCS keywords are banned, how do you cope?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在我 30 多年的整个职业生涯中，我从未使用过 VCS 关键字。 从我使用过的最原始的 VCS 系统到现在（TFS），我使用了一些其他结构来理解“我在哪里”。
我很少遇到只有一个文件可供使用的情况。 我通常已经获得了构建项目或项目集所需的所有其他文件。 我通常使用分支（或流，有时），并且我正在处理给定分支或流的某些部分。
如果我正在处理多个分支或流，我将为每个分支或流创建一个目录树。 要知道我正在处理什么文件，我需要做的就是检查文件路径，最糟糕的是。
最好的情况是，版本控制系统会准确地告诉您正在处理的文件的版本、更改历史记录是什么、还有谁正在处理该文件的不同版本，以及您想知道的任何其他信息。
I've never used VCS keywords in my entire career, over 30 years. From the most primitive VCS system I've used, up to the present (TFS), I've used some other structure to understand "where I am".
I am rarely in a situation where I've only got one file to work with. I've usually got all the other files necessary to build the project or set of projects. I usually use branching (or streams on one occasion), and I'm working on some slice of the given branch or stream.
If I'm working on multiple branches or streams, I'll have one directory tree for each. All I need to do to know what file I'm working on is check the file path, at the very worst.
At the very best, the version control system will tell you exactly which version of the file you're working on, what the change history is, who else is working on different versions of the file, and anything else you'd care to know.
这并不能完全回答你的问题，但我想 Linus 和 Guido 有理由不喜欢不适用于小团队企业开发的关键字。
例如，
$Id$标记具有您可以认为是全局版本号的内容。 Linux 和我猜想 Python 的开发都是碎片化的，没有一个数字可以是全球性的。 很多人都有自己的存储库，这些存储库会填写他们自己的$Id$值，然后这些补丁可能会被发送到 Linus 或 Guido 的存储库，在那里它们没有任何意义。但是，在您的环境中，您可能有一个中央存储库可以分配这些内容，这样就可以了。 听起来你正在使用 git。 我想知道是否可以配置中央 git 存储库来进行标签替换，而本地开发人员存储库则不能。 或者也许最好在标签中获取提交哈希。
This doesn't exactly answer your question, but I imagine Linus and Guido have reasons for disliking keywords that don't apply to small-team corporate development.
An
$Id$tag for instance, has what you could consider to be a global version number. Linux and I guess also Python development is fragmented enough that no number can be global. Lots of people have their own repositories all over the place that would fill in their own$Id$values and then those patches might be sent to Linus or Guido's repositories where they don't make any sense.However, in your environment, you probably have one central repository which would assign these and it would be fine. Sounds like you're using git. I wonder if it's possible to configure the central git repository to do tag substitution while the local developer repositories don't. Or perhaps it's better to get the commit hash in the tag.