小编dbs*_*rat的帖子

我无法找到一个好的分支策略,允许在我们的环境中轻松合并和跟踪变更集.

发布管理的快速摘要如下:

我们有几种商业产品作为解决方案的一部分.不可改变的外部因素导致我们必须无限期地维护软件的多个版本.发布过于频繁,通常是为了响应增强或缺陷列表以及非常激进的计划.仅修正版本通常是在父版本分支中维护的点版本.具有新功能的版本通常会成为新版本/分支.

源代码控制树如下所示:

- trunk - dev
  - Product ABC
    - ABC 1.0
      -  ABC 1.0.1 (point release same branch)
    - ABC 2.0
  - Product XYZ
    - XYZ 1.0
    - XYZ 2.0

Dev显然是我们的开发分支,预计不会稳定.通过同行评审的开发者更改被提升到主干,我认为这是稳定但仍然是开发代码.当我们向主干添加新功能时(通常是响应客户项目),我们最终接近发布,然后我将主干分支到上面的"Product ABC 2.0"这样的分支中.

当我们开始修复发布分支中的缺陷时,就会出现噩梦.我们希望将它们合并回主干,但它应该首先进入dev分支 - 但是由于分支是从主干创建的,所以除非我们对dev进行无根合并,否则这是不可能的.同样,如果我们在dev中进行更改并将它们移动到主干中并希望将它们再次合并到产品分支中,则无法进行无基础合并.

这似乎是一个错综复杂的分支计划,我确信这是完全错误的,或者没有好的方法来分支我们的模型以及我们为不同的客户做了多少版本和维护多年.

MS指南(甚至是高级高级计划)似乎基于更简单的发布方案.这里有什么我想念的东西可以带回一些理智吗？

我一直在寻找一些指导或大型表单(几十个字段 - 可能超过50个)的Web表单设计的示例,以便为将在应用程序上进行培训的用户群提供帮助.

99.9%的指导似乎是针对"可访问性"或"直观性",这些都是有效的目标.问题是,与将数据输入到业务应用程序的表单相比,可能在第一次(或唯一)时间遇到它的用户一次性或不经常使用的表单需要有很多不同的考虑因素.将在应用程序培训的用户全天重复使用.

• 如果我正在为一次性设计(比如注册表格),那么我想专注于设计表单,这样用户就会自然而然地完成自己的步骤并最终完成目标并感受到所有温暖而模糊.
• 如果我正在为有经验的用户设计每天使用20x的表格,他们会希望它的设计能够最大限度地减少点击次数和导航等.他们并不关心[外观]或天赋和微妙的提示.帮助他们完成表格.他们知道这种形式就像他们的手背,只是希望能够尽快输入数据,并在一个视图中尽可能多地查看.

我从用户那里得到的要求是他们希望在一个屏幕上看到"一切".他们不想滚动.他们希望尽量减少点击其他页面以继续工作.

有没有人有任何建议/链接/直言不讳？

谢谢,戴夫