更正过程以在新分支中使用挂起的分支更改 [英] Correct procedure to use pending branch changes in a new branch

问题描述

您提交拉取请求以将Branch A合并到主服务器.

You submit a pull request to merge Branch A into master.

虽然这是挂起的(大约1个小时)，并且您要在等待时使用分支A的挂起功能，但是您要使Branch B

While this is pending (1 hour or so) and you want to use the pending features of branch A while you are waiting, you make Branch B

应该Branch B是Branch A的分支

或Branch B应该是master的分支，然后合并Branch A

or should Branch B be a branch off of master and then merge Branch A

推荐答案

简短答案:使用另一个pullrequest可能很危险.您仍然可以开发B功能，有两种方法可以实现:

Short answer: using another pullrequest can be dangerous. You still can develop your B feature then, there are 2 ways to do it:

• 在A分支中对其进行开发，并更新原始的pull-request，使其包含这两个功能，或者
• 在临时分支(可以在您喜欢的任何地方)中进行开发，但在合并A以便掌握后，将您的工作重新建立到该合并上.

• develop it in A branch and update your original pull-request, so that it contains both features, or
• develop it in temporary branch (which can be anywhere you like), but after merging A to master rebase your work onto that merge.

答案:

在这里要注意的(但不是唯一)一件事是

One (but not the only) thing to beware here is the criss-cross merge. It may cause issues with conflict resolutions and sometimes even silently revert some changes. (Git claims some special care for this case, but I don't know how good it is.) It can happen even in you simple case, with the following steps:

• 从某些主提交a0
创建分支A
• 代码功能A
• 合并A，并在稍后再提交b0并在其中创建分支B
• 代码功能B
• 在请求合并过程中将A合并到主域
• 现在与主控方合并的B将是纵横交错的:

• create branch A from some master commit a0
• code feature A
• merge A and some later master commit b0 and create branch B there
• code feature B
• merge A to master during pull-request merge
• now the merging B with master will be cris-cross one:

您可以解决这个确切的问题.例如，您可以将master合并到A，将其前进到该合并，然后启动分支B.然后B的后续合并不会纵横交错:

You could fix this exact issue. For example, you can merge master to A, advancing it to that merge, and then start branch B. Then subsequent merge of B will not be criss-cross:

但是还有更多可能出现的问题.您可能有几个B分支.您可能有几个A分支.当您已经在使用B功能时，可能需要在审核后更新A. A可能根本不正确，应该以其他方式执行，或者根本不执行.您可能会尝试在每种情况下分析修订图并预测可能的问题.但是，如果您在团队中工作，则可能需要一个简单的策略来防止可能出现的问题.许多团队采用的这种策略最简单的情况是，它们不相互使用功能分支，而是从某个主提交开始所有这些功能分支.

But there are many more possible issues which can appear. You could have several B branches. You could have several A branches. You could need to update A after review, while you are already doing your B feature. It could happen that A is not correct at all and should be done other way, or not done at all. You might try to analyze the revision graph in each case and anticipate possible issues. But if you work in a team you probably need a simple policy which prevents possible issues. The simplest case of such policy, adopted by many teams, is that they do not use feature branches on top of each other, instead starting all of them from some master commit.

这篇关于更正过程以在新分支中使用挂起的分支更改的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！