使用Git将未合并的特性分支合并到另一个特性分支中 [英] Merge non-merged feature branch into another feature branch with Git

查看:103
本文介绍了使用Git将未合并的特性分支合并到另一个特性分支中的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我的公司的Git工作流程如下所示:


  • 从原始分支创建功能分支(我们使用名为base branch 开发,但您可以将其视为主)

  • 完成此功能分支中需要执行的工作并提交更改

  • 偶尔使用开发分支来重新绑定您的功能分支

  • 当功能分支中的工作完成时,提交并推送到GitHub上的远程功能分支

  • 创建一个pull请求,将您的功能分支合并到develop分支,由另一个开发人员审阅代码
  • 代码审查完成后,功能分支合并到开发分支和功能分支被删除



这适用于处理串行工作流程时,但是当您从您的功能分支推送您的更改,并等待其他开发人员检查并合并您的更改y你可能想要承担另一项工作,这意味着重复上述过程。

在我们的例子中,我们目前正在从开发分支创建我们的功能分支,所以我刚完成的工作还没有可用(它仍然处于闲置状态,等待由另一个开发人员合并到开发分支中)。我现在的问题是,如果我在我的功能分支中所做的工作取决于我刚才在我之前的功能分支中完成的工作?我是否应该最初将我的新功能分支从我尚未合并的功能分支而不是开发分支中分支出来?如果我已经从develop分支创建了我的新功能分支,那么从未合并分支中获取的更改就像执行 git merge [unmerged-branch] 在我的新分支内?



希望这个解释 - 以及工作流本身! - 说得通。我已经陷入了一些奇怪的情况,我不清楚我的代码的状态,所以我试图找出一个工作流程,该工作流程使我可以灵活地合并来自其他功能分支的更改,同时仍然可以获取任何上游更改时间。

解决方案


我的问题是,如果我在我的工作新功能
分支取决于我刚才在我之前的功能
分支中完成的工作?我应该从我的
开始分支我的新功能分支,而不是开发分支吗?




<你是这样描述的,是的,你会的。但是,我担心可能会走上未经批准/未经审核工作的路,就好像您的代码审查会导致重大变化一样,您可能会发现自己要重做很多工作。


如果我已经从develop分支创建了我的新功能分支,
正在将我从未合并分支中缺少的更改作为简单
做我的新分支内的git merge [unmerged-branch]?


是的。应该。 :)

My company has a Git workflow that looks something like this:

  • Create feature branch from pristine branch (we use a base branch called "develop", but you can think of this as "master")
  • Do the work you need to do in this feature branch, and commit your changes
  • Occasionally, rebase your feature branch with the develop branch
  • When the work in your feature branch is complete, commit and push to the remote feature branch on GitHub
  • Create a pull request to merge your feature branch into the develop branch, which gets code reviewed by another developer
  • Once the code review is completed, the feature branch is merged into the develop branch, and the feature branch is deleted

This works when you're dealing with a serial workflow, but when you've pushed your changes from your feature branch and are waiting on the other developer to review and merge your changes, you probably want to take on another piece of work, which means repeating the above process.

In our case, we're currently creating our feature branches from the develop branch, so the work I just completed isn't yet available (it's still in limbo, waiting to be merged into the develop branch by another developer). The question I have is, what if the work I'm doing in my new feature branch depends on the work I just completed in my previous feature branch? Should I be initially branching my new feature branch from my as-of-yet unmerged feature branch instead of the develop branch? If I've already created my new feature branch from the develop branch, is getting the changes I'm missing from the unmerged branch as simple as doing a git merge [unmerged-branch] within my new branch?

Hopefully this explanation -- as well as the workflow itself! -- makes sense. I've gotten myself into some weird situations where I'm unclear the state of my code, so I'm trying to figure out a workflow that gives me the flexibility to merge in changes from other feature branches while still getting upstream changes at any time.

解决方案

The question I have is, what if the work I'm doing in my new feature branch depends on the work I just completed in my previous feature branch? Should I be initially branching my new feature branch from my as-of-yet unmerged feature branch instead of the develop branch?

The way you're describing it, yes, you would. However, I'd be concerned about potentially going down the path of working off of "unapproved / unreviewed" work, as if your code review results in significant changes, you may find yourself redoing a lot of work.

If I've already created my new feature branch from the develop branch, is getting the changes I'm missing from the unmerged branch as simple as doing a git merge [unmerged-branch] within my new branch?

Yep. Should be. :)

这篇关于使用Git将未合并的特性分支合并到另一个特性分支中的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆