The problem:
task-a
task-a-branch
based on dev
branch to work on task-a
task-a
and create a pull request from task-a-branch
to dev
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
task-b-branch
based on task-a-branch
to work on task-b
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:
task-b-branch
and the related PR to include everything in task-a-branch
and it's related PRtask-b-branch
is probably a bit weird to review, as it doesn't just contain task-b
changes, but also task-a
changestask-b
when looking at the task-b-branch
PRtask-b-branch
cannot test it in isolationTo 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?
One suggestion if it works in your organization:
When you are done with task-a
, commit it, and ask for a merge of task-a-branch
on dev
.
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.
Finish task-b
and commit on task-b-branch
, but don’t ask for it to be merged yet.
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
.
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
.