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.
Post History
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 s...
#3: Post edited
by
hkotsubo
·
2022-01-10T14:01:26Z (almost 3 years ago)
Adding relevant info from the comments
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.
#2: Post edited
by
Alexei
·
2021-07-24T15:44:50Z (over 3 years ago)
added relevant tags
#1: Initial revision
by
Monica Cellio
·
2021-07-23T18:06:46Z (over 3 years ago)
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)