Stacked branches and PRs have conflicts due to squashed merges

Question

I use stacked branches as I develop main <- feature1 <- feature2 ..., as well as stacked PRs with feature2 PR'd against feature1 and so on. My company uses squash merge when going into main i.e. in GitHub (actually GitLab) when you merge your PR it squashes all the commits into one and merges that. So when I try to merge main back into feature2 it's a total mess of conflicts because feature2 has e.g. 5 commits from feature1 but main has only 1 commit with all the same changes.

After scouring the web what I've seen is that there is a very cumbersome almost unusable way of dealing with this using rebase and moving branch heads etc. There is also a new feature called update-refs which "handles" some of that mess for you.

My question is, 1) is there no other way to handle this situation that can be a bit more automatic or less painful. 2) if rebase --update-refs is the only way can someone list out some commands that would facilitate this. Here are some of the issues:

1. is there a command that will make it crystal clear what branches are stacked upon each other, which is the top which is the bottom and what are the commits in between that I have contributed and might need to move down.
2. if there is a conflict between feature 1 and feature 2 how can I avoid resolving that conflict for every commit between feature 1 and feature 5
3. is there a way to programmatically walk up the chain of branches to find the most upstream branch and the most downstream branch so I can say "git checkout most downStreamBranch; git rebase --update-refs mostDownStreamBranch;
4. if someone is doing this routine, can you share in detail your routine?

If this question looks familiar it's because I just asked it a couple days ago and they closed it saying it was dupe of a very basic question about how to merge branches. I couldn't get it reopened so I'm trying again.

Answer 1

My company uses squash merge

Yup. Well, if you don't want those conflicts, don't do that. It's a very bad policy. And what you are describing is one of the main reasons it's bad: if a branch (or a branch and its sub-branches) is long-lived and so gets merged in multiple times, merge conflicts are virtually inevitable. (If you don't understand why, read my https://www.biteinteractive.com/understanding-git-merge/.)

So, you need to either stop making stacked branches or else persuade your "company" to use real merges.