在版本控制环境中管理项目构建说明
最近，我们试图让测试人员在发布新的项目构建时更加清晰一些。
我们最初的想法是在项目中包含一个名为"BuildNotes“的Markdown文件(它是由源代码控制的)。我们编辑标记文件，然后生成一个他们可以读取的html页面。
在文件中，我们在顶部有一个名为Build-Next的部分。因此，如果您正在完成用户故事、完成任务或完成错误，则在您的分支上的本节中输入一个条目，然后通过PR将其合并到主分支中。
例如：
下一步构建
BUG 1234按钮不工作
Build-6
- 单击
User Story 5按钮保存文档。
现在，当这个分支被合并到开发中时，下一个构建就被推上了。文档被更新，来自Build Next的所有项都被移到新的构建部分，例如Build-7。
如果您正在处理一个任务，那么这个任务就完成了，然后转移到下一个任务上。但是，如果您在自己的分支中处理多个小错误，并且有3/4的分支正在等待PR，那么每次完成一个分支时，您都会遇到持续的合并冲突，那么其他分支都会与文件发生冲突，因为您总是在更新Build Next部分。
我们还有别的办法可以做到吗？我们可以在中用Bugs/Tasks标记我们的PR，然后这些标记显示在构建中，但是我们经常在构建文档中添加自定义注释，以便测试人员知道应该查找什么。
回答 2
Stack Overflow用户
发布于 2017-02-24 02:43:59
对于单个分支中存在的小bug，如果它们不相关，则可以单独构建它们。在构建定义中使用持续集成(CI)构建，因此每次分支合并到主分支时，都会触发生成。
如果这些bug是相关的，您应该解决冲突，直到所有PRs合并到主分支，然后开始下一个构建。
Stack Overflow用户
发布于 2017-02-24 09:22:43
你应该改变方法。与单一版本控制的文档不同，构建过程应该将构建文档生成为工件。例如，您可以有很小的每个分支注释(例如branch-note-BRANCH_NAME.md)，并且构建简单地将它们附加到不受版本控制的主文档中(或者驻留在它自己的存储库中)。
您将有两种构建风格:一种是将每个分支的注释文件连接到构建下一节的主版，另一种是连接构建N节的开发。您可以使用构建工具的一些API来选择构建标识符，或者在构建过程中标记repo。
https://stackoverflow.com/questions/42414146
复制相似问题
腾讯云开发者
