在Azure DevOps用户故事中，错误，任务和其他形式的工作项可以与git commit和Pull Request相关联。如果工作是在分支上完成的，然后合并到存储库的主分支（默认），则在查看提交历史记录时，将具有一个链接并可以查看关联的工作项。但是，当在与工作项相关联的第三级分支上进行提交，然后合并到第二级分支（称为“功能”）进行内部测试和审查之前，最终将其推送以掌握工作项时，仅与“拉”相关联请求而不是个人提交。我认为这是因为这些提交尚未合并到存储库的master（默认）分支中。功能分支上的提交没有直接链接到工作项。在通过直接合并或拉取请求将其他分支合并到分支之后，是否仍会在未标记为存储库的默认分支的分支上显示指向提交的工作项的链接？
我正在考虑将“功能”分支标记为默认分支。有一条与“功能”关联的CI / CD管道，与一条与master分支关联的管道，如果将“功能”分支标记为默认分支，则该管道仍将继续起作用。
如果采用这种方法，我还有其他注意事项吗？除了标记为默认分支之外，是否还有关于存储库master分支的“特殊”信息？
是否有更好的方法来实现目标？