CODEWITHSUNDEEP
git
Tim
Tim

Reputation: 99606

Will merging master branch into feature branch cause some problem in the future?

If I merge a branch B2 into a branch B1, does the merge affect that both branch might still grow with new commits created on or pulled onto them separately in the future?

For example, usually a feature branch is merged into the master branch. But while I am working on a feature branch, the master branch is being changed by collaborators. i want to update my feature branch, so i would like to merge the master branch into the feature branch. Will the merge cause some problem in the future, for example,

Thanks.

Upvotes: 1

Views: 1288

Answers (4)

Mark Adelsberger
Mark Adelsberger

Reputation: 45819

Since for whatever reason you have not inferred it from the fact that two people have told you it's a common practice:

No, it will not generally cause problems.

If it caused problems, it wouldn't be a common practice.

I say it will not generally cause problems because there could be some odd case where a combination of factors leads to spurious merge conflicts, and maybe some of those cases the type of merge you describe was one of the factors. But that is very much the exception and not the rule.

The only argument against the type of merge you describe is that some people dislike seeing repeated merges from master into a long-lived feature branch. These merges benefit the branch maintainer, not the overall project maintainer who is responsible for master; so when the latter has a huge ego, they see this as a problem.

The knee-jerk reaction is to rebase instead of merging into the feature branch. That's ok sometimes but there are two potential problems:

1) Once the feature branch has been pushed to origin, it's usually a bad idea to rebase it. See "recovering from an upstream rebase" in the git rebase documentation for a general explanation of why

2) Even if the branch isn't pushed, rebasing can commit intermediate commits that don't actually build cleanly (unless you're willing to re-test and fix each one every time you rebase). Arguably having "dirty" commits is a bad deal.

The other option, then, is to perform the merge for testing (to make sure you aren't deviating too much from master), then back out the merge with a reset. To help with the fact that this could create repetitive conflict resolution work, they've invented git rerere.

Of course that still means you probably have intermediate commits that don't build and test cleanly (because they were built and tested against a merge that was then taken out).

To my mind, backing out the merge and then using rerere to mitigate the damage is just a complex solution to a made-up problem. I have no problem with doing the merge and leaving it in place.

Upvotes: 0

sesamechicken
sesamechicken

Reputation: 1981

Typically you want data to flow in one direction, as in feature => master. This is where a rebase can come in handy. 

      A---B---C topic
     /
D---E---F---G master

is then rebased into

             A'--B'--C' topic
             /
D---E---F---G master

Src: https://git-scm.com/docs/git-rebase

Upvotes: 0

jingx
jingx

Reputation: 4024

It's actually part of a typical workflow to periodically merge changes on the main branch into your feature branch, because it keeps the feature branch reasonably up-to-date with what your collaborators have been doing, and reduce the risk of having messy merge conflicts when you are finally ready to merge your feature changes into the main branch.

Upvotes: 1

axiac
axiac

Reputation: 72425

Merging the master branch into a feature branch is a common practice. It keeps the feature branch up to date with the latest changes in the master branch.

This way it minimizes the risk of conflicts when the feature development is complete and it's the time to merge the feature branch back into the master branch.

Upvotes: 2

Related Questions