您对 SVN 分支和标签使用哪些命名约定？
我们公司正在为 SVN 分支和标签创建命名约定，我对在分支/标签名称上仅使用日期或内部版本号的想法感到不舒服。
我认为我们需要的名称能够更好地定义这条路径代表什么、正在做什么工作等等。
您认为/使用什么？
Our company is creating a naming convention for SVN branches and tags, and I'm not confortable with the idea of using only date or build number on branches/tag names.
I think we need names that brings a greater definition about what this path represents, what effort is being done, etc.
What do you think / use?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
我总是在标签（通常也是分支）前面添加 YYYYMMDD 格式的日期，后跟标签或分支用途的描述。
例如，20090326_Release_v6.5 或 20090326_Post_Production_Update
当然，这是在标准主干/标签/分支层次结构下。
日期前缀确保所有标签或分支都按创建顺序显示，如果您扫描一个大标签文件夹，这比仅按描述排序更有用。 您可以看到它们的创建时间和原因的时间线（例如迷你日志消息）。
I always prefix the tags (and usually branches too) with the date in YYYYMMDD format, followed by a description of the purpose of the tag or branch.
e.g., 20090326_Release_v6.5 or 20090326_Post_Production_Update
This is under the standard trunk/tags/branches hierarchy of course.
The date prefix ensures that they all the tags or branches are displayed in creation order, which is much more useful then just being sorted by description if your scanning through a big folder of tags. You see the timeline of when and why they were created (like mini log messages).
嗯，分支几乎是开放的，因为有几种不同类型的分支，它们的命名可能非常不同。
值得记住源代码控制为您提供了什么。 标签名称不仅仅是“v1.4”，而是“/CashCowProject/tags/v1.4”。 将标签命名为“/CashCowProject/tags/CashCowProject-v1.4”有点多余，还能是什么？
修订控制还使您可以完全访问标签的创建日期和时间。
修订控制还为您提供应该使用的提交消息，特别是第一行。
有了所有这些信息，就不难将一个简单的视图组合在一起，为您提供所需的所有信息，这些信息来自一致且适当的来源，例如：
标签名称在这里唯一真正有用的是版本号。 如果您尝试将所有信息放入标签名称中，那就有点啰嗦，而且我敢打赌它看起来不会那么好。
Well, branching is pretty much open, since there's several different kinds of branches, the naming of them can be very different.
It's worth remembering what source control gives you. Tag names are not just "v1.4", it's "/CashCowProject/tags/v1.4". Naming a tag "/CashCowProject/tags/CashCowProject-v1.4" is a little redundant, what else would it be?
Revision control also gives you full access to dates and times that tags were created.
Revision control also gives you commit messages which you should be making use of, particularly the first line.
Given all this information, it's not difficult to pull together a simple view giving you all the information you need, coming from consistent and appropriate sources, such as:
The only thing that the tag name is really useful for here is the version number. If you're trying to put all the information into a tag name, it's a little wordy and I bet it won't look as good.
对于功能分支，以正在执行的操作命名。 例如，我将 ORM 从 LINQ 迁移到 SQL 到 NHibernate，并创建了一个名为“NHibernate”的分支。 完成分支并将其合并回主干后，您可以删除该分支以节省将来的命名冲突。 如果您确实需要检索分支，则可以，您只需深入研究历史记录并恢复它即可。
如果您有与分支机构相关的故事/报价/工作编号，我会将其附加到分支机构的名称中，例如。 “NHibernate_429”，这样您就可以轻松地根据您的跟踪系统引用它。 然而，我总是首先选择英语，因为这是人们在开发时更现实地引用它的地方。
对于标签之类的东西，很难说出您想要做什么，因为这取决于您要标记的内容。 如果您要标记版本，那么我会使用“Release XXXX”或类似的简单内容。 当您回顾特定版本作为示例时，您实际上不会关心日期或版本号是什么。
For a feature branch, name it after what is being done. For example, I moved our ORM from LINQ to SQL to NHibernate and created a branch called "NHibernate". Once you have completed the branch and merged it back into the trunk you can delete the branch to save naming conflicts in the future. If you really need to retrieve the branch you can, you just have to delve back into the history and restore it.
If you have story/quote/job numbers that are relevant to a branch, I would append it to the name of the branch eg. "NHibernate_429" so you can easily reference it against your tracking system. However, I would always go with the English first as that's what people are more realistically going to refer to it by when it is in development.
For things like tags it's hard to say what you want to do as it depends on what it is you are tagging. If you are tagging releases then I would use "Release X.X.X.X" or something simple like that. You really aren't going to care what the date or build number was when you are looking back for a specific release as an example.
我们所有的开发人员任务都会进入错误跟踪系统。 该错误跟踪系统具有与每个任务关联的 ID。
因此，对于任何任务的分支名称，我们使用：
当分支包含多个 TicketId 时，我们只需将它们组合到分支名称中：
这样，如果您在票证中并且想知道要构建哪个分支，则可以轻松查找。 同样，如果您想在分支构建中找到票证，您也可以轻松找到它。
对于标签，我们通过版本号本身来标记它。
至于各个分店的位置。 我们有一个像这样的顶级层次结构：
然后我们所有的产品/项目都位于它们自己的子文件夹中。
All of our developer tasks go into a bug tracking system. This bug tracking system has IDs associated with each task.
So for the branch name of any task, we use:
When a branch contains multiple ticketIds we just combine them into the branch name:
That way if you're in a ticket and you want to know which branch to build, you can easily look it up. Likewise if you want to find the ticket with your branch build, you can easily find it too.
For tags, we tag it by the version number itself.
As for the location of each branch. We have a top level hierarchy like this:
Then all of our products/projects go under each of those inside their own subfolders.
我们使用什么（主要遵循公认的约定）：
在主干下，我们有主干。
在标签下，我们标记每个版本（内部版本、测试版本和客户版本）。 在那里我们只使用版本号作为标签名称。
在分支下，我们发布的每个主要版本都有一个分支（在我们的例子中是一次 XP 迭代的结果）。 它们的命名类似于主要版本（“v5.03”、“v6.04”）。 此外，我们还有用于重大更改或特殊版本的内部分支。 命名是自由形式的，名称应该告诉人们分支代表什么。
示例为“workaround_customerA”、“module_x_reorg”等。
What we use (mostly following the accepted convention):
Under trunk we have the main trunk.
Under tags we tag every release (both internal, testing releases and customer releases). There we just use the version number as the tag name.
Under branches we have one branch for every major version we released (in our case the result of one XP iteration). Those are named like the major version ("v5.03", "v6.04"). Additionally, we have internal branches for major changes or special versions. There naming is free-form, and the name is supposed to tell people what the branch represents.
Expamples would be "workaround_customerA", "module_x_reorg" etc.
我们给我们的分支一个“.X”版本，其中标签有一个数字。
例如，分支将是 Foo-1.2.3.X，标签将是 Foo-1.2.3.1、Foo-1.2.3.2 等。
我们还有一个特殊的标签 Foo-1.2.3.0，它是由一旦从主干创建分支，在进行任何更改之前。 这样我们就可以随时将分支和标签与初始状态进行比较（因为几天后，主干可能会有所不同）。 这种做法使合并变得更加容易，并且使弄清楚分支中的代码发生了变化变得更加容易。
We give our branches a ".X" version, where the tags have a number.
For example, the branch would be Foo-1.2.3.X, and the tags would be Foo-1.2.3.1, Foo-1.2.3.2, etc.
We also have a special tag, Foo-1.2.3.0, which is made as soon as the branch is created from trunk, before any changes. That's so we can diff branches and tags to the initial state at any time (since in a couple days, trunk is likely to be different). This practice has made merges a little easier, and it makes figuring out what code changed in the branch a whole lot easier.
更好：
例如：
XYZ_14_01_00
Better:
like:
XYZ_14_01_00