I’m working on a team project where the Git strategy is to do development on a dedicated branch (one branch per feature or bugfix), and regularly rebase master on this branch.

In the past, I always used merge, instead of rebase. Now discovering this different way of using Git, I’m surprised regarding one particular case: the handling of conflicts.

My understanding is when rebasing branch A to branch B, all commits from the branch A are being “replayed” on branch B. If there are conflicts, the repository ends up in a state of “interactive rebase in progress,” and one has to solve those conflicts one by one, while the commits are being replayed.

If branches were short-lived, this wouldn’t be a huge deal. But the teams has a history of long-lived branches, and it is not unusual to spend half an hour doing a rebase, and then do it again the next day. In general, for every rebasing step where a conflict is found:

• I accept current changes and ask Git to continue.
• If there is a file that was deleted and modified at the same time, I ask Git to delete the file.
• Once conflicts are solved, I ask to merge the changes and to continue the rebasing.

I’m wondering:

• Given the team constraints (i.e. rebase instead of a merge, long-lived branches, and a requirement to do rebases regularly), am I doing it right? Or is there a way to do the same thing, while having a workflow close to a merge, where I would be asked to help git to solve conflicts just once?

• If my approach is correct, how do I script it?