我们已经开始在我们的持续交付 (CD) 项目中使用 Git。我们的 DevOps 决定我们必须有一个干净的 Git 日志，其中每个气泡都与一个技术/用户故事相关联。在日志中，master 上的提交必须是来自功能分支的合并提交。日志不能超过一个级别（即，它应该看起来好像每个分支不与另一个分支重叠）。
例如：
到目前为止，我们通过创建一个本地分支、提交到这个分支并使用 master 重新定位，然后将分支合并到没有 ff 的 master 来实现这个目标。
但是，我不确定这种方法是否最佳。它在大多数情况下运行良好，但是当多个开发人员在同一个分支上工作时，他们无法使用 master 进行 rebase。因此，如果他们需要将分支代码与推送到 master 的一些更改同步，他们就不能（或者至少要复杂得多）
由于习惯了以前的源代码控制系统，我觉得由于 rebase 会丢失有关提交实际发生顺序的信息，因此很难理解发生了什么。
在具有上述约束的团队中工作的最佳实践是什么（日志必须看起来尽可能接近上图）？
这种日志结构给持续交付系统中负责发布的人带来的最大优势是什么？