经理阅读版本控制提交

我们的经理正在监视我们所有项目中的Git承诺；通常这不是问题，我喜欢这样一个事实，即版本控制提供了所有正在发生的工作的日志，尤其是对于以后的审核和分析（以防万一出现问题）。

但是，该经理发表了一些评论，询问人们在看到提交中看到“样式修复”的提交或在我们的任务管理系统中未引用故障单编号的任何提交消息时，人们在做什么。

有社会或技术解决方案吗？

进一步的信息：这是一个维护项目，因此发生了很多“必须先执行A，然后是B，然后是C，然后是D，最后要实现X”的任务。

更多信息：特定的提交消息向管理器发出了标志，它接近“包含了一种更好的X，Y和Z方式”，这更多是重构消息，而不是简单的样式修复。

有社会或技术解决方案吗？

我想，但这不是问题。

您的经理应该知道你们在做什么。他们应该确保您没有做一堆没有价值的工作，或者为什么要优先处理非票务工作。这没有害处。在理想的情况下，它将为您带来好处，因为您的经理可以对业务设定期望，这样您就可以在没有压力或中断的情况下完成所有工作。

仅当您的经理认为只应执行票务工作，并且排除技术清理工作成为票证时，这才成为问题。总会有技术债务需要清理。总是要进行调整，因为即使它们没有提供明确的直接业务收益，您也应该这样做。

如果样式修复程序是您正在使用的票证的一部分并且与之相关，那么将其与您正在使用的票证号分开签入以确保更好的识别就没有问题。

如果您只是发现需要进行的更改，而这些更改与您当前正在处理的票证无关，那么我建议您制作与技术债务相关的票证，并将其放入待办事项列表中，以供以后重新处理。

在计划过程中，您可以浏览与技术债务相关的票证，并将其附加到您打算以此方式进行工作的实际维护票证上，以使其更加相关。

这将帮助您消除那些“无处不在”的修复程序，并将所有内容封装在您正在处理的特定问题/故障单的类别下。

这也使我感到烦恼（没有双关语的意图：）。

最有用的签到内容包含独特的注释，不仅针对更改内容，而且还针对原因。我有时最终会在段落中添加注释。

我偶尔会遇到这样的情况，即开发开始后，UI要求就会来回反弹，这实际上也要求我反弹代码（是的，有时真实世界很糟糕）。在这些情况下，我的意见更重要的一点是，就是要清楚说明反弹的原因，更重要的是为什么代码会终止在它的原处，这一点更为重要。然后，当管理层在与客户交谈之后又回来并想知道为什么时，我可以向他们展示而不必记住整个体验。