我正在处理两个功能分支。功能A和功能B。功能B有生活质量更新,这些更新对测试任何代码(包括功能A中的代码(都很有帮助,但不是绝对必要的。功能B的代码更改与功能A的代码不重叠。事实上,在这种情况下,功能B、功能A和main之间的差异都包含在一个新文件中(尽管通常情况下,拆分可能不那么干净(。
最后,困难的限制是,功能B对其他开发人员来说优先级较低,因此在功能A被审查之前,不太可能被审查/合并到main中(否则,我可以将B合并到main,然后将main合并到A中(。
这是我想象中的工作流程:
- 将功能B合并到功能A
- 对功能A进行测试等
- 当功能A准备好合并到main时,我需要继续手动删除功能A中特定于功能B的所有更改
- PR功能A进入主
问题是第三步感觉有点粗糙。在我的特定情况下,功能B代码只是它自己的文件,这很好。但是,如果功能B中的代码可能是嵌入在其他文件中的一个类或几个函数,那么这可能会带来令人不舒服的工作量。有没有更好的工作流程来实现我的目标(除了先将功能B合并到main中(?
这每天都会很痛苦,当然之前的合并B是最好的。
您将需要3个分支机构A.BA+B
X---Y---Z A
/
D---E main
F---G---H B
X---Y---Z--
/
D---E---F---G---H--I A+B
你将在A+B上工作和测试。然后应该在分支A中推送修复程序。
你会花时间在分支机构之间切换,而混淆的风险就在这里。
一种方法是使用git commit --fixup
和git rebase -i --autosquash main
修改分支A的提交,您将修改提交X
、Y
、Z
您还可以使用git-rebase-i在合并之前移动提交。
X---Y---Z--
/
D---E---F---G---H--I A+B
假设你做p提交fixup! X
,Q应该添加
git commit --fixup=<X sha> files
然后
git commit #as usual
你会得到
X---Y---Z--
/
D---E---F---G---H--I--P--Q
你用autosquash重新设置基础,保留合并,你想要交互提示:
git rebase --autosquash -i --rebase-merges
你会得到
# Branch A |~
reset onto |~
pick c888803 X |~
fixup 17c9a48 fixup! X |~
pick bba9c0a Y |~
pick 931d75e Z |~
label A |~
|~
reset onto |~
pick d6e5233 F |~
pick a2852db G |~
pick 231e819 H |~
merge -C 712dfc2 A # Merge branch 'A' |~
pick e8d3984 Q
然后将Q移动到分支A,检查修正
# Branch A |~
reset onto |~
pick c888803 X |~
fixup 17c9a48 fixup! X |~
pick bba9c0a Y |~
pick e8d3984 Q |~
pick 931d75e Z |~
label A |~
|~
reset onto |~
pick d6e5233 F |~
pick a2852db G |~
pick 231e819 H |~
merge -C 712dfc2 A # Merge branch 'A' |~
你会得到
X---Y'---Q'---Z'
/
D---E---F---G---H-----I newA + B
为了检查一切是否良好,你将获得A和B那么你需要强制分支A到Z’
git branch -f branchA shaZ'