Is it possible in git to have a branch-like sequence of commits that gets applied on top of another branch?

Question

I have been using git for a long time and think am quite familiar with it, but I recently encountered an use case that is bothering me:

There is a main software development team that develops the main branch. This is a regular git branch and they develop using usual git practices.

Then there is a customer_A support team that develops customizations for customer A. This customizations involve modifying the code in main. What the customer_A team currently does is they develop their customizations in branch customer_A that they periodically rebase to main. The problem with this approach is that every time that they rebase they need to force-push, with the usual force-push drawbacks.

What I am wondering is if there is a way for team customer_A to develop in some "branch-like" fashion so their "branch-like" sequence of commits gets applied on top of main without needing to force-push their "branch-like" sequence of commits every time they want to rebase to the latest main branch.

Before you ask, the customizations for each customer involve modifying different pieces of code for different customers, and they are unpredictable until we talk to the customer. If they were always the same, this would be a typical use case: We would simply externalize the configurations into some configuration files developed in a different repo with each customer team developing their own configuration independent of main or other customer teams.

Answer 1

As I mentioned in a comment, for several months we tried the git merge approach. It was better than the git rebase and force push but the non-linear history is ugly and we were not completely happy.

Eventually we switched to using quilt to maintain a list of patches involving possible customizations as well as a series file for each customer listing which patches/customizations each customer gets. We use git to version control our patches and series files. We are very pleased with this approach and it addresses all our needs without any drawbacks. Unlike the git based approaches, the quilt approach feels completely natural for our workflow.

Answer 2

I've been experimenting a bit with a "more careful" way of doing merges to working/development branches while maintaining history in a reasonable way. The basic idea is that you never want to merge from main, only to main, so your main history always ends up "clean". The way you do this when bringing some other branch up to date is:

• first create a new temp merging branch on main
• merge your working branch (customer_A in this case) to the temp branch
• fast-forward the working branch (customer_A) to the head of the temp branch
• delete the temp branch

That's it. Once you do that, your working branch can still later be merged to main without screwing up the history, and the history on the working branch is reasonably clean (it is the main-line history with work-in-progress merged into it).

The fast-forward should work unless someone else has committed to the development branch while you're doing this (in which case you'll need to back out and redo this with their change included)