我们说我在分行branch-1。我做了一些更改并做了5次提交并在GitHub repo上打开了一个PR。
现在，我做了git checkout -b branch-2。然后我做了一些改进，并做了5次提交。 （注意，分支-2中现在共有10个提交）
现在，我做了git checkout -b branch-3。然后我做了一些改进，并做了5次提交。 （注意现在分支-3中共有15个提交）
现在，我做了git checkout -b branch-4。然后我做了一些改进，并做了5次提交。 （注意分支-4中现在共有20个提交）
现在，GitHub repo上有4个不同的PR对应4个分支。
现在，我的一些问题是： -
我做了git checkout branch-2并做了一些改进并提交了它们。现在，我如何将这些更改带回branch-3和branch-4？
在这种情况下还有其他有效的工作方式吗？我的意思是当你必须在Github repo上创建小PR但所有新分支依赖于以前的分支。
谢谢：）
答案 0 :(得分：2)
不要从依赖于其他PR的分支创建新的PR。
它使维护者更难以审查。
如果他在branch-2之前查看branch-1，
他会看到两者的所有变化，
这可能会一下子压倒一切。
然后，在审核branch-2后，如果他打开branch-1，
他会浪费时间阅读他已经审查的内容。
如果您想从依赖于另一个PR的分支创建新的PR， 要么等到第一个PR合并， 或考虑删除第一个PR。 这仍然不是一个很好的选择， 因为如果你创建了很多PR然后删除它们以取代另一个PR， 这可能是很多噪音。
还要问问自己这些分支是否需要相互依赖。
如果没有，那么从origin/master开始新的分支，
不是来自未决的公关。
如果branch-1已经开始处理依赖于branch-2的{{1}}上的评论，那么branch-1会收到评论，而不是问题。在branch-1中实施请求的改进，一旦接受，合并或重新绑定到branch-2。
在branch-1被接受后，
当您为branch-2创建PR时，
branch-1中的更改，包括更正，
将不再可见，
审核人只会看到branch-2的更改。
答案 1 :(得分：0)
1：您可以使用merge或rebase来完成。在这种线性情况下，我更喜欢rebase。
git rebase branch-2 branch-1
git rebase branch-3 branch-2
git rebase branch-4 branch-3