I'm doing some research on how companies use GitHub Enterprise (or public GitHub) internally. If you can help out by answering a few questions, I'd greatly appreciate it.
- What is the primary setup? Is there an organization and each official repo is owned by that organization?
- Does every engineer have a fork of each repo they're working on?
- Are engineers allowed to push directly to the official repo? Or must all commits go through a pull request?
- Do engineers work on feature branches on the main repo or on their own forks?
- Do you require engineers to squash commits and rebase before merging?
- Overall, what is the workflow for getting a new commit into the main repository?
- What sort of hooks do you make use of?
- Are there any ops issues you encountered? (Scaling, unforeseen downtime, etc.)
- Anything else worth noting?
Thanks very much for your feedback. I plan on coordinating all information into a blog post so we can all benefit from understanding these workflows.
First off, we've been using Git + Github for years now, and have barely deviated from our initial setup
Proprietary code goes into a single organization and each repo is the site/product itself.
Open-source (which we author & contribute heavily to) lives in the "owner's" own repo, for which the company may fork as needed, but that's rare.
We don't have any junior level developers (anymore), so that's no longer necessary. At the end of the day, forks were more cumbersome that solved zero problems compared to our excelling branching strategy.
Fast-paced, constant-commit projects use gitflow primarily for the following purposes:
feature/
branchesdevelop
master
is tagged & deployed automatically when (1) the test suite passes and (2) there are no db migrations in the releasehotfix/
branches which immediately go ontomaster
anddevelop
Because of this, the majority of changes all have an issue + PR associated with them, mainly because of a very strong, collaborative culture we have. It feels "wrong" doing changes onto
develop
because we're accustomed to someone else approving the RFC.Just as I mentioned above,
feature/
branches on the main repo. All feature branches have to be associated with an issue to avoid collisions (e.g.feature/12-new-admin-theme
andfeature/827-new-admin-theme
is totally common)Absolutely not. Rebasing is nice to have to avoid messing "trying to make this work" and "whitespace" and "stupid bug" commits, which are quite common when collaborating/sharing code that's difficult. But we also use commits as an accounting method rather than tracking time, so granularity is important.
git checkout -b 123-short-description-of-feature
orgit flow feature start 123-short-description-of-feature
hotfix
ed it, and redeployed. Ops are rarely needed.Yes, the issue->branch->PR workflow should be standard for the majority of active projects. Naming branches
123-some-feature
is huge for tracking issues to features, gauging velocity, and simplifying branch naming & conflicts.Contact me @ericclemmons for any other details.