You don’t have to squash to avoid merge commits. Instead, you can git rebase main to update your branch. Effectively, this will rewrite the history of your branch, as if you had just branched from the main-branch and then instantly coded all your changes on top of that. (Well, the commit timestamps won’t change, but they will sit on top of the changes of the main-branch.)
Afterwards, you should be able to merge into main by switching to it and then running git merge--ff-only your_branch.
Because all the changes sit on top of the main-branch commits, it should be able to fast-forward. No actual merging needs to take place then. You’ve already resolved any conflicts while rebasing.
This also allows you to keep branches for longer, so long as you frequently rebase and merge back.
You don’t have to squash to avoid merge commits. Instead, you can
git rebase mainto update your branch. Effectively, this will rewrite the history of your branch, as if you had just branched from the main-branch and then instantly coded all your changes on top of that. (Well, the commit timestamps won’t change, but they will sit on top of the changes of the main-branch.)Afterwards, you should be able to merge into
mainby switching to it and then runninggit merge --ff-only your_branch.Because all the changes sit on top of the main-branch commits, it should be able to fast-forward. No actual merging needs to take place then. You’ve already resolved any conflicts while rebasing.
This also allows you to keep branches for longer, so long as you frequently rebase and merge back.