Can ommiting a rebase onto master before merging MR with squash lead to any problems?

Question

We tend to rebase every branch after every MR is merged. It leads to a lot of unnecessary pipelines and so on. But we squash every MR into one commit.

So given there are no conflicts in merge requests, can omitting rebase onto master before merge lead to any problems?

Answer 1

You can probably skip the pre-merge rebase.

I can think of 3 reasons one might rebase the source branch onto the target branch before completing a MR (or PR):

1. There are conflicts and you must update the branch somehow. (Not applicable in your case.)
2. If you complete the PR with merge --no-ff then the resulting history would be cleaner, resulting in nice little merge bubbles. (Since you squash, this also is not applicable in your case.)
3. You wish to test the latest and greatest code before merging into the target. Even though it's generally rare for bugs to sneak in without merge conflicts, it's still possible, especially when multiple people are working on the same portions of the code. If you have good unit test coverage perhaps it's quick and easy to re-run them against the latest code prior to completing the MR, just in case.

Obviously #1 and #2 aren't applicable in your case, but if I were in your shoes, and I had good test coverage, #3 would probably be a good enough reason for me to blindly rebase and re-run the tests just in case. If I didn't have good coverage and didn't have an easy way to retest everything, I'd probably take a quick peek and see if I thought it was needed, and if not, I'd skip it.

Side Notes:

1. Since you're squashing, for both #1 and #3 you can accomplish the same thing by merging instead of rebasing. Choose whichever is easier for you. For example, if you're resolving conflicts and you have many commits, merging is oftentimes faster than rebase since it's one and done, compared to the worst case scenario of resolving conflicts for each commit during a rebase.
2. "But we squash every MR into one commit." Just a word of caution here. It's perfectly fine to squash feature branches into a target branch, but make sure you don't squash shared branches into each other. That just causes a mess for everyone. If you ever create MR's to merge one shared branch into another, only use a regular merge there.
3. While squashing may be convenient for minor changes, and for those who make many WIP commits without fixing them up, IMHO when a developer goes out of their way to make multiple good, meaningful commits, then I would prefer having all of those commits in the permanent history, since that's what the developer wanted.