i'm working on a project that uses gerrit. the basic premise is that you add a commit hook, which adds a 'change id' to every commit you make in a branch. gerrit parses the commit id when you push changes, then creates a 'change request' (similar to a pull request) and tracks 'patchsets' for all commits with a matching change id. you can follow the diff between base/patchset1/patchset2 for that change id. this seems to be good for facilitating trunk-based development, because you can work directly on whatever the main or dev branch is.

the company i'm doing work for doesn't want to see feature branch merge commits in the history, so i'm doing a lot of rebasing and squashing, and kind of like it. my regular workflow is feature branch, then merge the main branch into my feature & resolve conflicts whenever necessary. this leaves a messy history, especially with long-lived feature branches.

i kinda think i'm going to switch to rebase without --rebase-merges, but another guy i know says he hates this, because he can't see the merge commits in the history. he says the merge commits help isolate where and when the issue occurred, so i guess it's easier to punish the person who fucked things up.

idk, i see either way as being practical, but not rebasing definitely makes it easier to just do whatever. rebase takes more work/care/attention.