Git 标记提交消息和变更集

我正在寻找一种解决方案，在提交消息中标记变更集

对我来说，“标签”是这样的：

• 代码清理
• 用户可见的更改
• 修改数据库结构（ALTER TABLE）
• 文件更改

到目前为止，我使用SVN，但想切换到git。如果有标准的话，很多工具，比如trac，redmine。。。我可以用这个

我想用这个来回答这样的问题：

• 如果我更新了系统，客户可以看到哪些更改，或者 这只是一个维护更新吗
• 两个版本之间的数据库架构是否已更改

背景：

到目前为止，我使用unison在开发、测试和产品系统之间进行同步。但是unison对版本管理（目前是SVN）一无所知。我想换成git。我想快点看，有什么变化

---

示例：我希望看到测试和产品之间的更改。我不希望看到源代码更改，但希望看到提交消息。但有时最多有100次提交。这里我需要一个过滤器，以排除不重要的更改。

我喜欢使用以下标记：

ADD adding new feature
FIX a bug
DOC documentation only
REF refactoring that doesn't include any changes in features 
FMT formatting only (spacing...)
MAK repository related changes (e.g., changes in the ignore list)
TEST related to test code only.

此标记始终是提交消息中的第一件事，然后是简要说明和/或问题跟踪系统中的问题id（如果存在）

我将这些标签与svn和git一起使用，到目前为止，我发现它们非常方便

要回答您的编辑问题，请执行以下操作： 这就是为什么我喜欢那些提交标签。如果提交更改或不更改行为，它将立即可见。如果您的数据库方案定期更改，或者这些更改对您非常重要，您可以为此引入一个标记

我还喜欢在适当的地方将这些标记组合到一条提交消息中。例如，“测试foo的测试文档设置”

---

使用数据库的附加DB标记，您可以轻松跟踪与数据库相关的更改。

我更喜欢在问题跟踪器中为每个更改集分配一个问题。使用已知的问题跟踪器（如jira），可以选择在变更集中解决的问题。选择问题后，问题描述将自动放置在变更集的消息中。他们可以在将来跟进，也可以在您的问题跟踪程序中报告

我大部分时间都在使用Typo3中的标签系统：

它在提交消息中使用如下标记：

[TAG]Short message

当然，我总是弹出一个问题编号进行问题跟踪。我们正在使用JIRA，所以它将变成这样：

[TAG]JIRA-123短消息

Typo3标签：

可能的标记有：

• [功能]：一个新功能（也是小的附加功能）。它很可能是一个附加功能，但也可能被删除。这只能发生在v4的“主”分支中，因为旧分支中不允许使用新功能。例外情况必须在个案基础上与相应的发布经理讨论
• [错误修复]：对错误的修复
• [任务]：上述类别未涵盖的任何内容，例如编码样式清理
• [API]：API已更改，方法或类已添加或删除；方法签名或返回类型已更改。这仅指TYPO3的公共API

此外，在某些情况下可能会添加其他标志：

• [！！！]：打破改变。在这个补丁之后，一些东西的工作方式与以前不同，用户/管理员/扩展开发人员将不得不更改一些东西。应该只发生在“主人”上
• [WIP]：正在进行的工作。一旦更改的最终版本可用，此标志将被删除。标记为WIP的更改永远不会合并
• [安全]：可视化更改修复了安全问题。此标签由安全团队使用，如果您发现安全问题，请始终遵循，首先与安全团队联系

示例主题描述：

• [BUGFIX]在tslib_fe中抛出HttpStatusExceptions
• 已准备语句中的[BUGFIX][SECURITY]SQL注入漏洞
• [FEATURE][CONF]添加选项以隐藏列表模式中的BE搜索框
• [！！！][功能]将高级前端编辑移动到TER
• [！！！][任务]删除t3lib_sqlengine
• [！！！][API]从t3lib_userAuth中删除不推荐的方法重定向（）
• [API]为HTTP状态异常创建异常层次结构

---

我更新了问题。这些标签应该回答这样的问题：“如果我更新了一个系统，哪些更改对客户是可见的，或者只是一个维护更新？”如何处理与问题无关的提交？例如，如果你添加或更正了一些文档或重构了一些东西？@guettli：所有这些信息都保存在你的问题中。此外，其他信息，如请求更改的信息、应用此更改的源代码版本、受此更改影响的第一个版本等。。。在问题跟踪器上保留问题。@mort:作为SCM（软件配置管理）实践，系统中的每一项更改都应根据问题进行。@hsalimi:我不同意。考虑以下情况：您在代码中工作，发现一些内联注释包含拼写错误，但与问题数据库中的任何问题无关。你是做什么的？为拼写错误创建问题只是为了能够将提交连接到问题？我只需使用“DOC FIX spelling”之类的提交消息来提交拼写错误的更正。这样，当扫描提交历史记录时，您可以立即看到，您不必仔细查看这个特定的提交。+1是一个很好的答案。但是，如果我需要使用标签了解更多关于更改的信息，该怎么办？e、 我需要更多地了解一个缺陷（它的报告者，它的关键性，它的复制品）