Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Users Search
Help Dashboard Sign In Sign Up
Q&A Code Reviews Meta
Q&A
Posts Tags Edits
Ask Question

Welcome to Software Development on Codidact!

Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.

Comments on What's the correct way to merge a branch and its dependent branch back to master?

Post

What's the correct way to merge a branch and its dependent branch back to master?

+14
−1

In git I branched feature-A from master. To reduce eventual merge conflicts later, I branched feature-B, which heavily overlaps and depends on A, from feature-A. A build of the feature-B branch shows both sets of changes, as expected. (There have been no further commits on feature-A after this branch.)

What is the best way to land both features back on master? If I just merge feature-B, will it bring along its feature-A baseline, or just the feature-B-specific changes? I think a branch is a set of commits and a commit is a set of deltas, so my concern is that merging feature-B to master would reflect only the work that is unique to feature-B, and without feature-A it would break. But my mental model of git might not be correct.

Alternatively, I could merge feature-A first and then feature-B. That seems safe, but I don't know if it's the best way.

A third approach would be to merge feature-B back into feature-A and then merge feature-A, which came from master originally, back to master. I'm reluctant to do that because that breaks the isolation between feature-A and feature-B; if in the future I need to backport feature-A but not feature-B, I'm not sure how I would do that.

Goals:

  • feature-A and feature-B are both on master and arrive in that order (or together)
  • it remains possible to backport feature-A without bringing along feature-B in the future (I do not have to support the reverse)

In order to provide more details, that's what my repository looks like:

$ git log --graph --format="%ad %h [%p] %d"

Fri Jul 23 10:42:47 2021 -0400 725d9d1c11 [ca99f826dc] (HEAD -> feature/ct-comparisons-VER-75425, origin/feature/ct-comparisons-VER-75425)
Thu Jul 22 16:27:48 2021 -0400 ca99f826dc [6498847a48]
Thu Jul 22 11:05:17 2021 -0400 6498847a48 [9b2ddff48d] (origin/feature/null-rows-VER-74021-VER-75002, feature/null-rows-VER-74021-VER-75002)
Thu Jul 22 11:02:59 2021 -0400 9b2ddff48d [37329f2ec7]
...

feature/null-rows-VER-74021-VER-75002 is branch A and feature/ct-comparisons-VER-75425 is branch B, and I want to merge both to master.

git git-branch branching-strategy
posted over 3 years ago
3y ago by hkotsubo‭
user card
Monica Cellio‭ staff
2510 reputation 14 35 345 58
History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.
Why should this post be closed?

1 comment thread

If I understood correctly, just merging B is enough, as B was branched from A (thus, B "contains" al... (10 comments)
If I understood correctly, just merging B is enough, as B was branched from A (thus, B "contains" al...
hkotsubo‭ wrote over 3 years ago
copy link

If I understood correctly, just merging B is enough, as B was branched from A (thus, B "contains" all A commits, as there were no further commits in A). Can you add the output of git log --graph --format="%ad %h [%p] %d", just to confirm how your repo history is?

Monica Cellio‭ wrote over 3 years ago · edited over 3 years ago
copy link

$ git log --graph --format="%ad %h [%p] %d"

  • Fri Jul 23 10:42:47 2021 -0400 725d9d1c11 [ca99f826dc] (HEAD -> feature/ct-comparisons-VER-75425, origin/feature/ct-comparisons-VER-75425)

  • Thu Jul 22 16:27:48 2021 -0400 ca99f826dc [6498847a48]

  • Thu Jul 22 11:05:17 2021 -0400 6498847a48 [9b2ddff48d] (origin/feature/null-rows-VER-74021-VER-75002, feature/null-rows-VER-74021-VER-75002)

  • Thu Jul 22 11:02:59 2021 -0400 9b2ddff48d [37329f2ec7]

...

Monica Cellio‭ wrote over 3 years ago · edited over 3 years ago
copy link

Not sure what I'm looking at; does this help? (Lots of older stuff from master, as expected.)

Monica Cellio‭ wrote over 3 years ago
copy link

The latest two commits there are on feature-B; the previous two on feature-A; previous ones from master.

hkotsubo‭ wrote over 3 years ago
copy link

I'm guessing that feature/null-rows-VER-74021-VER-75002 is branch A and feature/ct-comparisons-VER-75425 is branch B, and you want to merge both to master, right?

Monica Cellio‭ wrote over 3 years ago
copy link

Correct. I was going to massage that output to match the feature names in the question, but I didn't want to accidentally remove something important.

hkotsubo‭ wrote over 3 years ago
copy link

I've answered the first part (merge both A and B). Regarding the second part ("backport feature-A without bringing along feature-B in the future"), I didn't understand what you want to do...

Monica Cellio‭ wrote over 3 years ago
copy link

Thank you! That explanation is very helpful, and I think you've answered my other question. In the future I might need to merge feature-A, without feature-B, into a previous release's branch, so I was looking for a solution that wouldn't pollute that. I think in that case I'd just merge feature-A into release-whatever, same as if feature-B never existed. I just need to isolate A from B; if B gets backported A would have to too.

hkotsubo‭ wrote over 3 years ago
copy link

Yes, in this case, if you merge only branch A, it won't include B. Another alternative is to apply specific commits, using cherry-pick: https://git-scm.com/docs/git-cherry-pick

Monica Cellio‭ wrote over 3 years ago
copy link

Thanks. We usually do backports by cherry-picking the commit to master (so, merge feature-x to master, then cherry-pick that commit to release-foo). That wouldn't work in this case because feature-A isn't coming to master in its own commit, but we could cherry-pick the last commit on that branch instead. Thanks again for the help and for straightening out my mental model!