Smart people with strong opinions. What can you do. I've come from a merge workflow into a rebase (git + gerrit) workflow in a huge software project with hundr

Smart people with strong opinions. What can you do. I've come from a merge workflow into a rebase (git + gerrit) workflow in a huge software project with hundreds of people. Rebase workflows are fine. Merge workflows can be fine. Personal preferences + the way you're used to doing things. There's some advantages to being able to see how conflicts were resolved when you're looking for something that went wrong but if you have code reviews and tests then the probability of needing that in a rebase workflow is smaller. In a large team "how we got to a change" is IMO less interesting than "this is the change". Have seen occasional breaks from things that were incorrectly rebased (generally from auto-rebase situations), but those are rare enough and easy to address. Same things can happen with merges. An IMO much larger question is branching strategy. Normally if you're following a rebase workflow you're doing trunk based development. Many teams that use a merge workflow use feature branches. If you use feature branches you're pushed towards merge workflows. That's a bigger debate maybe (and I'd vote for trunk based).