DEV Community

Discussion on: git workflows - between forks, squash and rebase

Collapse
lirantal profile image
Liran Tal Author

The two options I provided aren't contradicting actually but are completing each other.

To your points:

  • With only a master branch you refer to a trunk-based development workflow. I think it's a too extreme workflow, plus requires an increasingly high level of git mastery to work with, and also I actually want to utilize the benefits I get with a PR workflow (facilitating code review, tests feedback loop, etc). Plus, it doesn't allow ad-hoc external contributors to participate.
    I understand the feedback loop/integration issues you're referring to but the PRs and fork's own feature branches are short-lived (days to maximum of a sprint)

  • Definitely their branches (or the PR branch actually) needs to run the full test suite, but if I manage merge+squash through a PR then they don't need to specifically use rebase but rather a simple merge of master into their branch would yield the same (as long as this is all contained in their own branch still). Or do you think there's any benefit still with rebasing even on their own branches? I'm trying to nail the rebase vs merge of master to their own branch.