REBASE BEFORE CREATING A PULL REQUEST

Especially if you've had to pull from main 7 times. No one has pulled from your branch, you have no excuse!

I really don't see the point, since you can diff between branches?

I've seen some rebase purists advocate for this approach but 90% of teams/ projects just do a merge from main prior to the MR, it's simpler and safer, especially for inexperienced devs. No big deal having an extra merge commit. You can still exclude it from the log with --no-merge option.

@webketje if you have made changes over time and merge without rebase it can be much harder to afterwards see the actual changes since other commits can have come in between and I have seen that make finding dome logical errors very difficult.

Sure, in many cases its no problem and if no one has changed the same area a rebase is redundant.

But the rebase will make the history of main more clear since even if you committed to your own branch, other devs did not develop towards some of those commits which means they might have other expectations on the outcome of a method than after your merge.

Squash anyone? 😅

@ScriptCoded While is sometimes is good, if you made several distinct changes for the same feature I often leave them as separate commits.

I know this could be dictated by policy but in our case we decided that the different commits can be more informative.

Of cause, if you have hundreds of commits per week squashing can be more important.

No rebase - no pull!

@ScriptCoded exactly: first rebase, then squash, then pull