4 ms·

Feature branch, review, squash, merge - only way to roll imho.

• umvi 8y ago
  The question is how the merge should be enforced. Should the developer have to rebase their feature branch or not? The advantage of rebasing is that you can run CI on the rebased branch, and if it passes, it's guaranteed to pass post-merge. Not so for non-rebased merges. The downside of rebasing is that you need some kind of queuing mechanism for pull requests so that developers aren't constantly rebasing and racing each other to get changes in.
• int_19h 8y ago
  Squash or not depends on the nature of the change. Sometimes it can be a feature branch with enough work in it that rolling it all up into a single large commit is doing a disservice to somebody who's going to be doing code archaeology later while debugging.
  • jtms 8y ago
    For longer running larger features I would use interactive rebasing to selectively squash the larger feature into several more bite sized commits that declare intent and then merge that
• seba_dos1 8y ago
  No squashing. Unless your log consists of developer diary instead of properly fragmented logical changes - in this case squash before final review (and not necessarily into a single commit).
• yawaramin 8y ago
  Indeed, and if they're using GitHub, there's actually a 'Squash & Merge' option that can be enabled for all PRs (and possibly the other options can be disabled also). This keeps the feature branch history in the PR, but squashes and merges a single commit into master. Best of both worlds!