CODEWITHSUNDEEP
gitgithubmergeworkflowgit-flow
王岩华
王岩华

Reputation: 51

Can we merge develop branch into Feature branch in git-flow?

  1. Can we merge develop branch into feature branch in git-flow ?

  2. As shown in image below, there are 2 feature branch (A(red) and B(blue) ), assigned by two developers. When B need some code from A, will it be allowed that A push to develop go on coding, then B pull it from the develop?

  3. A merge develop branch, which didn't merge but overwrite, why, and how to solve it?

Upvotes: 4

Views: 7866

Answers (1)

Mark Adelsberger
Mark Adelsberger

Reputation: 45819

1) Teams may differ on this as some think the "unnecessary merges" make history ugly, but I see no problem with merging develop into feature branches. An alternative if you think it makes history cleaner (and haven't pushed the feature branch yet) would be to rebase the feature branch forward, but that might break the intermediate commits on the feature branch.

2) Incomplete features should not be merged into develop. develop should be ready for a release at any time. Cleanly sharing changes between feature branches is tricky (and, in a reasonably agile methodology with small stories/features, usually unnecessary). Most ways to do it involve some compromise. See below.

3) I'm not sure why you'd have seen that behavior; may need more information about how you attempted the merge. You can undo the merge (best if this is done without the merge having been pushed) by checking out the branch and doing something like git reset --hard HEAD^

Ok, so how to share the code if you have to? Well, if you take my advice not to merge A into develop, you might instead think "can I merge A into B directly?". Well, it's better than merging into develop to soon, but means that B cannot be safely merged to develop until A has been (because it would carry in a partial implementation of A).

If A hasn't been pushed, then you might do an interactive rebase of A to move the changes on which B depends up to the beginning of A, and then rebase B onto the commits that have the common changes. But that could involve splitting commits, and might create broken intermediate states, and depends on the branches not having been pushed (or everyone has to recover from upstream rebase)... all around not easy to do.

Another option is to cherry-pick the changes from A onto B. This is also a sort of rebasing operation, but it leaves all existing commits as they are (so no worry about if things have been pushed). But it still isn't so easy if the shared change is in a commit that also has other changes; and it will probably ultimately lead to conflicts when merging the features back into develop.

All around, just better to avoid this situation whenever possible. If feature B depends on feature A, maybe hold off on feature B until feature A has been properly merged to develop or something.

Upvotes: 6

Related Questions