Strategies for keeping long-lived feature branches up to date with master?
Hello Git gurus. Me and my team are in bit of a pickle with keeping our current feature/release branch up to date with what's happening on our master branch. To give some background, I'm working at a semi-large international company where we have devs in Europe, Asia, and South America. Currently, me and my team have been working on a feature branch for a while, and it's planned to live until November this year. We are around 10 devs all contributing with squashed PRs to our feature branch. However, our other international teams are all contributing with squashed PRs to the master branch, where those PRs are a mix of deeply embedded systems, new features for other clients, or refactors of old systems.
The first few months of our project we rebased our feature branch against master every week or so, and that was mostly fine until we were around 100 squashed PRs ahead of master. Then it started to take developers full weeks just to rebase our feature branch, which was completely unsustainable. Since then we have switched to instead merge master into our feature branch every week, taking in all the new changes. That worked well at the start, but now we are several hundreds of PRs ahead of master and it's again starting to take several days to merge master into our feature branch.
From my point of view, our troubles stem from a combination of these issues:
- Our PRs merged months ago relied on the state of master then, since then master has changed, so the old PRs are in a sense invalid. This means that when updating our feature branch we have to go in and fix old PRs, which only adds to the ever growing problem.
- We are refactoring old systems to fit our new features, and that does not always go into master. Sometimes this is because the refactor is extremely invasive to long-living systems, but crucial for our project. So in that case those refactors have no purpose living in master as any faulty changes may impact our clients' satisfaction rates. Other times they don't get merged to master because of human error.
- Our feature branch is progressing at a normal pace, a couple of PRs merged per day. However, the master branch is growing at maybe 50 PRs per day. When I say PRs, it's anywhere from 1 to 2000 lines of code changed per pull request. So at worst, a weekly merge of master could involve tens of thousands of lines only coming from master. I don't think it's a very normal amount of code to handle each rebase or merge.
So I've been thinking for a while now, me and my team can't possibly be the only ones with a long-living project like this. I'm wondering how other teams in similar situations have tackled this problem.
Our discussions so far around combating this problem has included things like:
- We merge everything to master but hide it behind compilation flags or macros (this is an embedded C++ project)
- This is not feasible due to business secrecy. Regulatory bodies (and sometimes clients) regularly decompile our software, and there can be no traces of my team's project what so ever. Merging everything to master feels like us begging to fail the project by leaking information to clients or competitors.
- We suggest to other teams that invasive changes that are merged to master are also merged to our feature branch.
- This feels like a huge overhead that we are bringing to other teams, which have different priorities, clients, and funding/budgets. Because of that this also feels infeasible.
- We start doing nightly merges of master into our feature branch. Whenever a merge fails, one developer has to go and either discard the merge completely, or patch it up so that we can update our feature branch.
- This makes the problem more granular, but doesn't combat it. Instead of a dev wasting 3 consecutive days of work, they might waste 4 hours every day of the week. So in a sense this would only automate the "easy" part, which isn't very helpful.
So I'm wondering if any other large, cross-team codebase has found a better way to work like this with long-living projects? Or have me and my team just found ourselves in a very weird position? Thanks in advance.