Git is very flexible and this is what makes it great, everyone can adopt their own workflows. So without going into a flame war I'm hoping to collect some opinions:
Situation: for a SaaS product that will benefit from CI/CD, the team (4-12 engineers), working with github private repos and leveraging pull-requests to merge work from feature branches to a single master branch.
- what would be pros/cons for using a single repo and all the team opening feature branches in it, vs the github workflow where team members fork and work in their own repo to create PRs from.
- if the pull-request merge strategy is to squash (done using GH's button on the PR), then there's essentially no reason for members to rebase on their own branches if the sole purpose of it is to squash the commits.
Oldest comments (3)
I think discussions like this are always interesting to read, I'll be keeping an eye on this thread as it evolves.
TL;DR:
In general I'd suggest thinking about having your team work exclusively on your master branch to truly work with CI.
However, of the two options you've provided. I'd choose to work with PRs on a single repository, having your developers continuously rebase on master and run the full test suite to ensure that their work in progress isn't introducing failures into your master pipeline.
Longer version:
As a starting point I'd like to address something. You say that you'd like to benefit from Continuous Integration (CI) and Continuous Delivery (CD) as you build out this product. Yet your two workflow options centre around forking or PRs.
I'm interested in why the option to have all of your developers commit directly to master isn't on this list? Otherwise you'd be practicing something like "Occassional Integration" wherein the true integration of new features/code only occurs after a branch has been merged back in to master.
It may seem like nit-picking, but the variance in the feedback loop there is significant and can create serious pain in a development team if not managed correctly.
To your question about merging PRs and the need to rebase:
If you're looking to get a continuous sense of whether or not feature branches are introducing build failures to your master branch, you'll need your developers to frequently rebase their branches on master and continuously run the full test suite on those branches. As I mentioned before, waiting until a branch in merged back in to master before verifying that it integrates successfully creates a very slow feedback loop.
You can configure your CI pipelines to automate a good deal of this (i.e. run a new build for every commit on every branch) however it can get very expensive from an infrastructure and time perspective.
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.
I do think that each project should have his own repository. Imagine that you're a developer working on the project X, and someone ask you to revise a PR in the project Y. In order to run the test suit of Y in your machine, you need to drop everything that you're working on the project X and switch your current branch.
Also, there is one point much more important: git history. If you have one repo for all projects, you will have a giant history and it may be harder to navigate in the history.
About squashing, I personally prefer not to use it. Merges is my preferred way to go, but I do no see any problems of squashing changes instead of merge.