具有多级分支深度并通过合并请求合并的Git和团队资源管理器

我们使用TFS并且最近（在上个月内）切换到Git VC。我们制定了策略，因此不允许手动合并到主分支中。相反，我们有拉取请求的策略，只有在拉取请求获得批准时才允许合并。具有多级分支深度并通过合并请求合并的Git和团队资源管理器

我遇到以下情形：

创建的本地分支BranchA从master
开发完成上BranchA，从BranchA打开相对于master
拉入请求创建的本地分支BranchB，如BranchB依赖BranchA中的代码
完成开发BranchB，拉动请求相对于打开BranchA

我理解的Git没有引入请求的概念，严格来说，合并分支机构一起不构成真正的关心。那就是：

BranchB合并BranchA合并master仅仅是因为这样做 BranchB合并master细，然后BranchA合并master

我挣扎辨别清晰的方式来拉时进行合并涉及请求。我所做的是：

为BranchB完全拉入请求其合并到BranchBBranchA
完全拉请求BranchA其合并到BranchAmaster

不幸的是，这种做法引起BranchA的pull请求将被更新为来自BranchB的最新更改，这些更改膨胀了请求并取消了它的原始意图（因为现在有更多文件需要查看）。

如果我切换订单，那么BranchA拉请求完成后，我必须确保远程分支不会被删除，因为BranchB依赖于它的存在（这是一个假设，也许TFS将拉请求从物理分支？）。

如果我让BranchB的拉动要求相对master，然后拉请求将包括BranchA和BranchB变化，因为master不知道的还BranchA。

我正在寻找任何有关如何处理这种情况的建议，而不会膨胀拉请求。

来源

2017-02-24 Sam

你可以在你的第二个场景中删除分支就好了，分支不是特定提交上的“标签”。只要还有其他提交仍然引用这些提交，它们就不会消失。你怎么能加快合并过程，所以BranchB可以开始主人？ – jessehouwing

啊，这是一个非常好的点，我记得很重要，分支只是标签，提交是真正的交易。所以在这种情况下顺序并不重要，'BranchA'可以先合并。至于加速合并，这是一个让团队其他成员完成审查和批准代码的问题（我们的合并策略在合并发生之前需要两个批准者）。理想情况下，这些拉动要求是短暂的，但情况并非总是如此。另外，我通常会在打开“BranchA”的拉取请求之后立即准备好在“BranchB”上启动开发 – Sam

A pull request是fetch后跟merge。就像你在评论中说的分支只是标签一样，提交是真正的交易。

对于您的案例，解决方法可能会合并两个分支中的拉请求。例如，直接从BranchB相对于master创建拉请求。拉取请求被接受后。至今在BranchA合并它你可以简单地做在您的本地回购：git checkout的BranchA，git merge与BranchB（或提交你试图用merge），然后git push当地BranchA分支到远程回购的BranchA分支。

git checkout Branch A 
git merge Branch B 
git push origin Branch B

来源

2017-02-27 10:21:30

具有多级分支深度并通过合并请求合并的Git和团队资源管理器

回答

相关问题