|
Sorry, but no, a branching workflow won't scale if you have thousands of developers pushing to the same repo. Those pretty `git log --all --decorate --oneline --graph` images won't work when you've got thousands of branches, and the history on the mainline will be poor and of low utility. What I was taught almost 20 years ago at Sun Microsystems (RIP) is a rebase workflow. That was back before Git. We were using Teamware of all things, and we were using it with a clean, linear upstream history workflow. Our particular rules were: - linear history upstream
- absolutely no merge commits (at Sun
they were called "merge turds")
- one commit per-bugfix, though one
commit could fix more than one bug,
with a separate commit for test
changes
- one commit per-project
- but otherwise one push could push
many commits
We also had rules about commit titling, naturally.Sun had been using that workflow since 1992 as I recall, so they used that workflow for 16 years, with several thousand developers pushing to OS/Net (core of Solaris). We even had rebase --onto. The workflow for projects went like this: - devs push to a project clone of the upstream
- gatekeeper takes care of build issues and
preps to push to upstream when project is ready
- every so often the project repo ("gate") would
rebase onto the upstream head, then devs would
rebase their clones onto the new project head
- eventually the project would rebase onto and
push to the upstream
- project repos ("gates") got archived when the
projects completed
That workflow scales very very well. The resulting upstream's history is very clean, with just: commits for bug fixes, commits for tests for bug fixes, commits for projects, commits for release-making, and the occasional follow-up to a commit that fixed minor issues with that commit (e.g., `12345 Crash in blah blah (fix style)`).I strongly recommend it. |