Git Merging Branch Into Master

If you have a branch which you forked off of master and then developed your feature in it...when it comes to merging back into master, I've heard 2 different approaches:

  • First merge master into the feature branch, and then merge the branch back into master.
  • Merge your branch into master.
  • Can anyone tell me which method is better and if there's an actual benefit to the first?

    Or if there's a better method ?


    Let's say you create feature-sev from master, and meanwhile, I create feature-eric. My branch modifies the same file as yours; in fact, it happens to overlap in a way our git client isn't clever enough to understand. I finish development first and merge my changes in.

    In this situation, you're inevitably going to be prompted to resolve the conflict.

    CONFLICT (content): Merge conflict in stackoverflow.html
    Automatic merge failed; fix conflicts and then commit the result.
    

    If you went with (1), merging master into the branch and making sure everything looks good, you'll resolve the conflict via a merge commit in feature-sev. If you make any mistakes during resolution, you can roll them back without any direct modification to master. This is good.

    If you went with (2), you'll resolve the conflict via a merge commit made directly to master. If you make any mistakes, you will break master. This is bad.


    I guess it depends ;-)

    Some things to consider:

  • Do you need the feature branch any longer after merging? If so, it might be useful to merge master into it as well as merging back to master . If not, it does not make too much sense to merge to the feature branch if you are going to delete it anyway.
  • Is it okay for you to break your local working copy of the master branch? If not, you should avoid merging code into master which may result in lots of conflicts you need to resolve manually. If it is okay, proceed.
  • In general I'd say it depends on how you work with git.

    As I generally use feature branches only temporarily and I delete them after successfully finishing a feature and having merged them into master , I usually merge directly into master and delete the other branch afterwards.

    On the other hand, I can imagine that there may be situations where it may be useful to do it the other way round. But as long as there are no strong reasons I'd try to avoid it. One merge is enough ;-).


    Theoretically, there is no difference. You have a set of changes in one branch that you're combining with a set of changes in another branch. It doesn't really matter where those changes end up.

    In practice, it's better to merge changes into the feature branch, because it gives you an isolated place to resolve conflicts. This is especially important if the feature branch has been under development for a long time, as there are often subtle conflicts that will be resolved after the first commit.

    The best approach is to take regular updates from master to feature branch, reducing the likelihood of conflicts at the end of feature development.

    链接地址: http://www.djcxy.com/p/68180.html

    上一篇: Chrome v23不支持视口缩放或视口元标记?

    下一篇: Git将分支合并为主