我们在我们的一个项目中使用了 develop
分支开发模型。
o - - - A - o - o - o - o master
| \ /
\ o hotfix1
\ \
o - B - o - o - o develop
在上图中,hotfix1
是必需的,我们在 master
和 develop
分支中应用( merge )它。这导致 2 个不同的提交 ID A 和 X。
稍后我们需要一个新的修补程序,它再次应用于 master
导致提交 C:
o - - - A ... A - - - C master
| \ / \ /
\ M hotfix1 N hotfix2
\ \ \
o - X - o - o - o - ?(A, N)? develop
但是将 hotfix2
merge 到 develop
分支中,我们在 merge 请求(GitLab 术语)中得到以下提交列表:
N
A
这有几个缺点:
- 代码审查者将看到比提交 N 中更多的更改,即使所有这些更改已经在
develop
中(通过提交 X)。这使得审查变得更加复杂。 - merge 后,在
develop
中我们看到 X 和新引入的 A(通过 merge N)。像这样,我们在两个不同的提交中有相同的更改和相同的 git 提交消息 (git log
)。
我们如何避免在 master
和 develop
中重复提交?我们想继续使用 develop
分支模型。
最佳答案
您可以挑选 (git cherry-pick <commitHash>
) 包含修复的提交,而不是在开发中 merge 修补程序(分支),它将创建以下内容:
o - - - A ... A - - - C master
| \ / \ /
\ M hotfix1 N hotfix2
\ \
o - X - o - o - o - N' develop
N' 将具有与 N 相同的内容,但父级不同,因此哈希值不同,而且,没有相同的父级意味着在您的 merge 请求中,A 将不存在。
关于git - 使用 develop 分支 Git 流程开发模型应用修补程序时,如何避免 Git 中的重复提交?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/55538770/