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 »

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.

Review Suggested Edit

You can't approve or reject suggested edits because you haven't yet earned the Edit Posts ability.

Approved.
This suggested edit was approved and applied to the post almost 3 years ago by Monica Cellio‭.

38 / 255
What's the correct way to merge a branch and its dependent branch back to master?
  • 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 `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:
  • ```none
  • $ 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.

Suggested almost 3 years ago by hkotsubo‭