Git将修补程序分支合并到功能分支 [英] Git merge hotfix branch into feature branch

查看:78
本文介绍了Git将修补程序分支合并到功能分支的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

假设我们在Git中遇到以下情况:

Let’s say we have the following situation in Git:

  1. 已创建的存储库:

  1. A created repository:

mkdir GitTest2
cd GitTest2
git init

  • 在主服务器中进行一些修改并提交:

  • Some modifications in the master take place and get committed:

    echo "On Master" > file
    git commit -a -m "Initial commit"
    

  • Feature1从master分支出来,并完成了一些工作:

  • Feature1 branched off master and some work is done:

    git branch feature1
    git checkout feature1
    echo "Feature1" > featureFile
    git commit -a -m "Commit for feature1"
    

  • 同时,在主代码中发现一个错误,并建立了一个修补程序分支:

  • Meanwhile, a bug is discovered in the master-code and a hotfix-branch is established:

    git checkout master
    git branch hotfix1
    git checkout hotfix1
    

  • 该错误已在hotfix分支中修复,并重新合并到master中(可能在请求请求/代码审查之后):

  • The bug is fixed in the hotfix branch and merged back into the master (perhaps after a pull request/code review):

    echo "Bugfix" > bugfixFile
    git commit -a -m "Bugfix Commit"
    git checkout master
    git merge --no-ff hotfix1
    

  • 功能1的开发仍在继续:

  • Development on feature1 continues:

    git checkout feature1
    

  • 说我需要在我的功能分支中安装此修补程序,也许是因为该错误也发生在这里.如何在不将提交复制到功能分支的情况下实现此目标?

    Say I need the hotfix in my feature branch, maybe because the bug also occurs there. How can I achieve this without duplicating the commits into my feature branch?

    我想防止在功能分支上获得两个与功能实现无关的新提交.如果我使用请求请求,这对我来说尤其重要:所有这些提交也将包含在请求请求中,尽管已经完成了(因为此修补程序已经在主服务器中),但必须进行审查.

    I want to prevent to get two new commits on my feature branch which have no relation to the feature implementation. This especially seems important for me if I use pull requests: All these commits will also be included in the pull request and have to be reviewed although this has already been done (as the hotfix is already in the master).

    我不能执行 git merge master –ff-only :致命:无法快速前进,中止."但是我不确定这是否对我有帮助.

    I can not do a git merge master --ff-only: "fatal: Not possible to fast-forward, aborting.", but I am not sure if this helped me.

    推荐答案

    我们如何将master分支合并到feature分支中?简单:

    How do we merge the master branch into the feature branch? Easy:

    git checkout feature1
    git merge master
    

    在此处强制快速向前合并没有意义,因为它无法完成.您已将其提交到功能分支和主分支.现在快进是不可能的.

    There is no point in forcing a fast forward merge here, as it cannot be done. You committed both into the feature branch and the master branch. Fast forward is impossible now.

    看看 GitFlow .它是git的分支模型,可以遵循,而您不知不觉中已经做到了.它也是对Git的扩展,它为新的工作流程步骤添加了一些命令,这些命令会自动执行您原本需要手动执行的操作.

    Have a look at GitFlow. It is a branching model for git that can be followed, and you unconsciously already did. It also is an extension to Git which adds some commands for the new workflow steps that do things automatically which you would otherwise need to do manually.

    那么您在工作流程中做了什么?您有两个分支可以使用,feature1分支基本上是GitFlow模型中的开发"分支.

    So what did you do right in your workflow? You have two branches to work with, your feature1 branch is basically the "develop" branch in the GitFlow model.

    您从master创建了一个修补程序分支,并将其合并回去.现在你被困住了.

    You created a hotfix branch from master and merged it back. And now you are stuck.

    GitFlow模型要求您还将修补程序也合并到开发分支,在您的情况下为"feature1".

    The GitFlow model asks you to merge the hotfix also to the development branch, which is "feature1" in your case.

    所以真正的答案是:

    git checkout feature1
    git merge --no-ff hotfix1
    

    这会将修补程序内部进行的所有更改添加到功能分支,但仅 .它们可能与分支中的其他开发更改冲突,但是如果最终将功能分支合并回master,则它们不会与master分支冲突.

    This adds all the changes that were made inside the hotfix to the feature branch, but only those changes. They might conflict with other development changes in the branch, but they will not conflict with the master branch should you merge the feature branch back to master eventually.

    在重新定基时要非常小心.仅当您所做的更改仍位于存储库本地时才重新设置基准,例如您没有将任何分支推送到其他存储库.Rebasing是一个很好的工具,可让您在将本地提交提交到世界之前将其本地排列成有用的顺序,但是事后重新打包将使像您这样的git初学者感到困惑.

    Be very careful with rebasing. Only rebase if the changes you did stayed local to your repository, e.g. you did not push any branches to some other repository. Rebasing is a great tool for you to arrange your local commits into a useful order before pushing it out into the world, but rebasing afterwards will mess up things for the git beginners like you.

    这篇关于Git将修补程序分支合并到功能分支的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

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