3 ms·
We have a team of 50 and single branch works well for us. > merge conflicts are preferable to changes that overwrite other changes Nobody is saying that. The
by Negitivefrags 11y ago
We have a team of 50 and single branch works well for us.
> merge conflicts are preferable to changes that overwrite other changes
Nobody is saying that. The difference is really merging as you go vs doing one big merge at the end. I personally fall on the side that it's far easier to merge as you go.
- techman9 11y agoYou merge as you go in branched development too? Master is typically periodically pulled into the feature branch to ensure you're working against the most current version of the codebase. EDIT: Yes, this can create an ugly revision history, but that's what rebasing is for, right?
- lowmagnet 11y agoWe rebase main branch into feature branches constantly. We rebase to squash reviewed features, and then ff down to the main branch to integrate the feature. If something doesn't integrate well, we commit the appropriate fixes locally, squash locally (if necessary) and pull/rebase/repeat on changes. It sounds crazy now that I write it down, but it really keeps our commits clean.
- zeendo 11y agoIf everyone is working in feature branches then you're still merging less often. Until you've merged your work into master then I'm not merging it into my feature branch. That leads to bigger merges than if everyone is committing to master all the time. Pros or cons of each aside, advocates of feature branch based development should recognize that they are merging less often than they would if they were doing trunk based development.