merge - How to manage sequential dependent branches in Git? - Stack Overflow

admin管理员组

文章数量:1394759

The problem:

• I receive a task task-a
• I create a new branch task-a-branch based on dev branch to work on task-a
• I finish working on task-a and create a pull request from task-a-branch to dev
• I then have task-b to work on and I can't wait for someone to review and complete the PR from task-a-branch to dev
• task-b happens to be dependent on the work I did on task-a, so I can't create a new branch task-b-branch based on dev
• I have no choice but to make task-b-branch based on task-a-branch to work on task-b
• Everything is sort of fine until I finish working on task-b and now I need to create a PR from task-b-branch to dev

At this point the problem isn't really a major one, but some silliness ensues. I often comment on the task-b-branch PR that task-a-branch should be merged first as this one is continuation on that and while all of this technically works, it:

• Feels weird for task-b-branch and the related PR to include everything in task-a-branch and it's related PR
• task-b-branch is probably a bit weird to review, as it doesn't just contain task-b changes, but also task-a changes
• Git (e.g. Gitlab) shows changes and diffs unrelated to task-b when looking at the task-b-branch PR
• It feels inherently wrong or awkward to have (small) task/feature branches depend on each other
• If, say, we had a couple of testers who did manual testing, the one who takes on the task to test task-b-branch cannot test it in isolation

To visualize this:

Dependent case (problematic)

Independent case (no problems)

The ideal scenario is when the task-a and task-b are independent of each other. Both task-a-branch and task-b-branch can be created based on dev, both branches can be merged in any order and both branches PR's contain only isolated changes.

Some thoughts

I wonder if this is really a GIT issue even? In certain cases this issue can be solved by simply merging the task-a and task-b into one task and working on both in, say, task-a-and-task-b-branch. This seems to be a good solution when the tasks are closely related to each other.

However, there are times when maybe task-a has something to do with e.g. how the front end fetches things from somewhere (maybe it's about updating/refactoring the API communication process in general) and task-b is some simple new feature where we fetch some stuff somewhere and show it in a table. In this case task-a and task-b are unrelated in a task/feature sense, but as task-a makes changes to front end's API communication process which task-b utilizes, task-b is still dependent on task-a.

---

So what would be a good way to handle such situations? Is there some GIT magic that could be done to e.g. filter out changes in task-a-branch when looking at task-b-branch for review etc.? Is it ever a good idea to have dependent branches like this? Or is this whole thing symptom of broken development process?

The problem:

• I receive a task task-a
• I create a new branch task-a-branch based on dev branch to work on task-a
• I finish working on task-a and create a pull request from task-a-branch to dev
• I then have task-b to work on and I can't wait for someone to review and complete the PR from task-a-branch to dev
• task-b happens to be dependent on the work I did on task-a, so I can't create a new branch task-b-branch based on dev
• I have no choice but to make task-b-branch based on task-a-branch to work on task-b
• Everything is sort of fine until I finish working on task-b and now I need to create a PR from task-b-branch to dev

At this point the problem isn't really a major one, but some silliness ensues. I often comment on the task-b-branch PR that task-a-branch should be merged first as this one is continuation on that and while all of this technically works, it:

• Feels weird for task-b-branch and the related PR to include everything in task-a-branch and it's related PR
• task-b-branch is probably a bit weird to review, as it doesn't just contain task-b changes, but also task-a changes
• Git (e.g. Gitlab) shows changes and diffs unrelated to task-b when looking at the task-b-branch PR
• It feels inherently wrong or awkward to have (small) task/feature branches depend on each other
• If, say, we had a couple of testers who did manual testing, the one who takes on the task to test task-b-branch cannot test it in isolation

To visualize this:

Dependent case (problematic)

Independent case (no problems)

The ideal scenario is when the task-a and task-b are independent of each other. Both task-a-branch and task-b-branch can be created based on dev, both branches can be merged in any order and both branches PR's contain only isolated changes.

Some thoughts

I wonder if this is really a GIT issue even? In certain cases this issue can be solved by simply merging the task-a and task-b into one task and working on both in, say, task-a-and-task-b-branch. This seems to be a good solution when the tasks are closely related to each other.

However, there are times when maybe task-a has something to do with e.g. how the front end fetches things from somewhere (maybe it's about updating/refactoring the API communication process in general) and task-b is some simple new feature where we fetch some stuff somewhere and show it in a table. In this case task-a and task-b are unrelated in a task/feature sense, but as task-a makes changes to front end's API communication process which task-b utilizes, task-b is still dependent on task-a.

---

So what would be a good way to handle such situations? Is there some GIT magic that could be done to e.g. filter out changes in task-a-branch when looking at task-b-branch for review etc.? Is it ever a good idea to have dependent branches like this? Or is this whole thing symptom of broken development process?

• git
• merge
• version-control
• branching-and-merging

Share Improve this question Follow asked Mar 27 at 8:40 SwiffySwiffy 4,72533 gold badges2727 silver badges5656 bronze badges 2

• Rest assured that this development process is normal. However, you should be very careful that you always rebase task-b-branch on top of task-a-branch in case you make changes in task-a before it is merged. Otherwise, you do get into trouble. (But that's still not an indication of a broken workflow, but only of an inattentive developer.) – j6t Commented Mar 27 at 12:56
• Thank you both, I believe doing these suggested rebasings is the key to solving this problem. – Swiffy Commented Mar 28 at 15:11

Add a comment  | 

1 Answer 1

Sorted by: Reset to default 2

One suggestion if it works in your anization:

1. When you are done with task-a, commit it, and ask for a merge of task-a-branch on dev.

2. Create task-b-branch based on task-a-branch, or actually (the way it works in Git) based on your last commit on task-a-branch, like you suggested.

3. Finish task-b and commit on task-b-branch, but don’t ask for it to be merged yet.

4. When your task-a fix has been merged into dev, do git rebase dev in task-b-branch. If there are conflicts, fix them and commit again on task-b-branch.

5. Now the situation is as if you had created task-b-branch based on dev after the task-a fix was merged. So you ask for a merge of task-b-branch on dev.

本文标签： mergeHow to manage sequential dependent branches in GitStack Overflow