Git工作流来审核提交而无需重写历史记录

Question

我正在与一个刚接触git的开发人员合作,我想设置一个git工作流,让我审核这个开发人员的提交(并可能拒绝他们)而不强迫他改变他的工作(这很容易出错)对于新用户).

这是场景:

• 该master分支仅包含经过审核的代码
• devel分支是由分支master分支创建的
• 开发人员正在devel分支机构上工作并推送他的代码供我审核
• 我发现他的代码存在一些问题,所以我请他在devel分支上做更多的提交以解决问题
• 一旦我对代码感到满意,我会挑选(或合并壁球)开发人员在master分支上提交,添加我自己的注释并将提交标记为开发人员编写的
• 开发人员将master分支合并回他的devel分支

以下是此方案的直观说明:

在这个序列之后,如果开发人员在其他一些提交之后再次推送他的分支,我怎么能100%确定开发人员在"犯错/重做"序列期间犯的错误不会再出现devel？

最好的解决方案是让开发人员devel反对他的分支master,但这对新git用户来说是一项艰巨的任务.

如果这个工作流程有任何错误,请建议我另一个我可以在将它们合并到主分支之前审核提交的地方.

编辑

一位朋友向我建议了一个看起来很有希望的方向:提交时的--fixup选项.

--fixup=<commit>

构造一个用于的提交消息rebase --autosquash.提交消息将是指定提交的主题行,前缀为"fixup!".有关详细信息,请参阅git-rebase.

开发人员可以使用此选项将第二次和第三次提交正确标记为第一次提交.探索的好方法......

Answer 1

备注1:通过尝试将分离的提交打开devel为单个提交master,您将重写历史记录.我看到了尝试保持干净,线性历史的重点master,但是合并的线性较差的历史将更容易与git基本命令集成.

备注2:如果您的工作流程明确包含不熟悉您用于共享代码的基本工具的成员,那么您应该承担后果.在某些时候,我认为开发人员应该学习git.

这有两个建议:

1. 删除master上的线性历史记录,并通过从master运行来"验证"更改:

   git merge --no-ff devel
   

   这是为了通知了修改git的最简单的方法devel是考虑到上master.

2. 与devel自己合并,让开发人员从中进行修改origin/devel.
   如果master上的单个提交实际上只包括压缩提交devel,则不应该触发任何冲突 - 合并提交master- > devel应该引入0修改.
   如果你实际上修改了压扁的提交,并且开发人员可以对他自己进行本地修改,那么无论如何你都必须面对触发冲突的可能性......

Answer 2

如果你只是要压缩dev分支而不是正常合并它，那么将压缩的提交合并回分支并不是一个好主意dev，因为这样你会遇到大量令人困惑的冲突，因为 git 认为你是应用新代码，而实际上它实际上是相同的代码。

最好要么简单地合并到master，然后简单地合并回devel，或者丢弃该devel分支并从最近提交的 中创建一个新的分支master。根据您的说法，只要您合并的代码master是“好的”，那么您可能不会得到任何回归。

另一方面，如果您按照最初的计划将压缩的提交合并回，那么由于令人困惑的冲突，devel这将增加发生回归的机会。

更新

我删除了上面的部分答案，因为我实际上只是测试了执行挤压提交master，然后立即将其合并回devel，并且它没有引起任何冲突，所以我的答案的这一部分是不正确的。

我将其转变为社区维基的答案，因为它在评论中仍然包含有关该问题的大量信息。