在工作中,我们在功能分支模型之上开发,所有集成最终都在master
分支中结束。我们从 分支master
并合并到master
。这导致了一个非常复杂的历史图表,我们正在寻找简化开发工作流程的方法。
这样做的一种方法是rebase而不是merge。但是,我们安装了一个内部 GitLab 实例,其中禁用了覆盖权限(并且不会仅为我们的项目启用它们)。因此,rebase是不可能的。
老实说,我没有看到任何解决方法。但我不是 Git 专家,我可能会遗漏一些东西。
有什么建议么?
在工作中,我们在功能分支模型之上开发,所有集成最终都在master
分支中结束。我们从 分支master
并合并到master
。这导致了一个非常复杂的历史图表,我们正在寻找简化开发工作流程的方法。
这样做的一种方法是rebase而不是merge。但是,我们安装了一个内部 GitLab 实例,其中禁用了覆盖权限(并且不会仅为我们的项目启用它们)。因此,rebase是不可能的。
老实说,我没有看到任何解决方法。但我不是 Git 专家,我可能会遗漏一些东西。
有什么建议么?
编辑-我的第一个答案绝不是最好的方法,尽管它会起作用。我把它留在下面以防任何人感兴趣。更好的答案如下:
您可以将git cherry-pick与一系列提交一起使用,featurebranch
以一次将一个提交应用到master
. 任何提交范围规范都可以,但在您的情况下,最简单的可能是(主检出):
git cherry-pick featurebranch ^master
这意味着“在 featurebranch 上挑选不在 master 上的所有东西”。
旧的,糟糕的解决方案
您可以使用git format-patch和git am。
在 branch 上featurebranch
时,running将为不在 on 上的git format-patch master
每个提交生成一个补丁文件。然后,您可以切换到并应用带有.featurebranch
master
master
git am
featurebranch
(在没有与任何人共享的更直接的情况下,您可以改为 rebase against ,而不是 rebase against master
,这将在顶部制作一个带有额外提交的副本,然后 rebase against ,这将使 git 快速-前进。)featurebranch
featurebranch
master
featurebranch
master
master
featurebranch
master