gitmergeversion-controlbranching-and-merging

How to manage sequential dependent branches in Git?


The problem:

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:

To visualize this:

Dependent case (problematic)

problematic dependent case

Independent case (no problems)

independent case without 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?


Solution

  • One suggestion if it works in your organization:

    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.