代码之家  ›  专栏  ›  技术社区  ›  Troy Hunt

来自同一用户的相同连续提交消息

  •  3
  • Troy Hunt  · 技术社区  · 15 年前

    我m正在为我们的颠覆用户准备一些SCM指导方针,并遇到了与团队的争论点。有没有一个有效的用例可以让某人连续提交相同的消息?

    如果采用提交消息应该描述代码的__what_ and__why_157;的方法,那么很难看到有效的情况。从我们的历史来看,发生这种情况的实例似乎比其他任何事情都更加不方便,而且确实不能说明代码正在做什么。

    有人对这件事的合法性有什么看法吗?指导方针(甚至是预提交钩子)是过于热心还是合理的期望?

    编辑: 让_的工作假设人们已经在留下好的提交消息。imho,像_156;updated_157;或_156;typo_157;这样的单个单词并不构成令人满意的提交消息。我希望看到一些更像更新颜色的提交按钮为绿色或固定打字错误的教学副本。如果消息是一个字或两个字,那么浏览存储库日志并理解项目中正在进行的操作而不钻取单个提交是非常困难的。

    6 回复  |  直到 15 年前
        1
  •  1
  •   Michael Dillon    15 年前

    对。 这主要是因为在提交消息的使用和目的方面的培训不足。最好定期寻找这些信息,并与执行此操作的人员联系,告知他们良好的描述性提交消息的重要性。如果人们知道如何写一个好的承诺信息,那么你只会看到偶尔的心不在焉。

        2
  •  6
  •   cadrian    15 年前

    我想这是技术解决方案无法解决的问题。您总是可以找到有效的案例,工具将禁止或相反。

    提交消息的一个例子,我经常使用,并讲述了所有的故事:

    typo
    

    最好的解决方案不是技术性的。这是社会工程。与你的团队交谈。

        3
  •  3
  •   chaos    15 年前

    我通常编写非常高的抽象提交消息,因为我不太明白要讲相同的故事, diff 做。这有时会导致相同的连续提交消息。

        4
  •  2
  •   Erich Kitzmueller    15 年前

    同一源文件上有相同的提交消息…臭。

    在不同的源文件上提交相同的提交消息,并连续提交:可能是正常的,如“添加了额外的日志记录”。

        5
  •  1
  •   Greg    15 年前

    如果我在两个不同的目录中做了相关的更改(在项目中可能被广泛地分隔开),我会这样做。它比查找一个公共根目录,然后取消选择许多不相关的更改或搜索我想要签入的更改容易得多。

        6
  •  0
  •   Rook    15 年前

    我不明白为什么这很糟糕…你不能每次都描述你做了什么…否则,你的大部分时间都会用很多词来描述那些实际上不存在的东西。

    例如:

    commented here and there
    typo
    tidyed something ...
    

    (我头上举的例子…)

    所以,例如,“打字错误”——意味着,如果我想编写好的提交消息,我应该用10个以上的字符来描述一个字母中的更改。以其最好的形式出现的专制…