Github非常棒。 我已经使用了很长时间了，它很棒。 它很容易上手，尤其是对于一个人的项目，它确实有助于使事情井井有条。
但是，当您开始添加团队成员，相互竞争的优先级以及整体复杂性时，情况会有所变化。 在很多方面，Github都开始表明它不是为长期软件项目而设计的，它具有许多团队成员和不平凡的工作流程。
以下是您可能已经在处理的一些事情：
- 您已经创建了很多标签，因此您已经写了一个Wiki页面来告诉所有人如何使用它们（以及如何不使用它们！）
- 也许您想分别跟踪错误和支持记录。
- 也许您认为开发人员不应仅通过提交代码就可以关闭故障单。
- 也许您已经厌倦了必须在Google Docs，Basecamp，Slack和Github中进行搜索以找到谈论该新功能的位置。
- 可能是您需要管理相互依赖或相互阻止的任务之间的关系。
我将针对每个主题写一篇博客文章。 本周，让我们从第一个标签开始。
标签
标签快速且易于使用，提供了很大的灵活性，并且几乎不需要设置或配置开销。 Github中的默认标签如下所示：
对于98％的新Github项目，这些可能都很好。 但是，随着时间的流逝，大多数团队将在标签列表上进行扩展，以包括与默认列表不同的值，甚至包括不同类型的数据。 在管理积压订单时，为类型 ， 优先级和状态之类的基础添加类别非常有意义。 但是，所有这些新值将使您的清单超出了您的直觉。
那么，团队如何才能可靠地使用复杂的标签集？ 一种常见的约定是使用前缀词来标识每个标签所属的组（由Dave Lunny提供）：
这种方法的好处是将标签的类型包括在标签文本中，因此您不会在“ 状态：测试 ”，“ 环境：测试 ”和“ 任务类型：测试 ”之间感到困惑。 在视觉上，各种颜色可用于显示特定值的差异，例如生产与非生产，或高优先级与低优先级。
不利的一面是，在按标签类型查看时，不同的颜色会造成混乱甚至彻底的震颤。 您实际上必须读取每个标签值，而不是基于颜色的快速视觉信号。 当查看单个任务时，这已经够糟糕的了，但是当浏览任务列表时，它可能会变得很混乱。
另一种方法是使用相似的颜色进行分组。 这是一个示例（来自robinpowered.com）：
尽管它看起来更轻松，但您不再需要将标签类型包含在标签值中。 另外，这组特殊的标签以您以后不会理解的方式组合和分离了许多值-例如，为什么生产标签是“问题”而不是“环境”？ 某处Wiki页面上可能有信息，说明您在生产环境中没有选择“环境”中的任何内容，对吗？
下一个示例根本不是一个示例，而是一个警告性的故事。 想象一下，与这些人一起进入第一天：
这也不是某人的毒品幻想项目，它是伺服，是Github上非常活跃且受欢迎的项目。
适用于您的工具的工具
为了响应这种广泛的需求，实际上有一些工具（例如git-labelmaker）专用于帮助Github用户使用不同的命名约定，颜色方案和标签样式来自动创建和管理复杂的标签集。 这很酷-除了看起来要完成很多工作之外，不是吗？ 如果有人创建了一个工具来帮助您使用其他工具，则可能是错误的工具。
标签/标签功能从未设计用于复杂的值或工作流程。
合适尺寸的解决方案
可以考虑使用以下布局（而不是由前缀词或配色方案组织的各种标签的混搭）（显而易见的是，IMO有一些附加功能）：
分离这些不同的关注点还可以使您灵活地在创建任务时要求某些字段，并为其他任务等待工作流程中的正确步骤。 您可以允许您的工具为您执行此任务，而不必手动执行任务管理过程。
最后一个好处-如果您使用单独的字段而不是特定的标签值，那么更改字段名称或随时间推移的值不会破坏旧数据。 新的字段名称或值将自动反映在较旧的任务中。
如果您的工具阻止了您改进流程，那么也许该是时候完善您的工具了。
很快回来，可能是另一个迹象表明您可能已经超出了Github的规模-下次，我们将讨论Github的一维任务跟踪。
快来尝试GForge Next，以进行简单，全面和优雅的协作。
