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.
BBC News
There is a BBC News organisation and an administrator account which assigns different users (i.e. BBC staff) access to our private repos.
No, engineers pull down the master branch and create a new feature branch.
Small changes (such as documentation updates or very small CSS tweaks) can be pushed to master (which fires off a build) but otherwise we open a pull request almost immediately (or at least once some initial work is carried out) and that way the GitHub interface allows all team members to comment on the feature and help discussions about the feature before it's finished.
Engineers pull down the master branch and create a new branch for each feature they're working on.
No, we don't enforce that type of rule although that is recognised as a best practice and encouraged. We also prefer to rebase when merging opposed to the more blunt 'git pull' technique.
Once the feature is completed locally on an engineer's computer (part of that will be writing acceptance tests in Ruby and unit tests in PHP/JavaScript) then the engineer will need to run a code sniffer and ensure all cucumber and PHP/JavaScript tests are passing. Then they'll assign the pull request to a particular team member and/or set a mile stone onto the pull request such as 'ready to merge'. The engineer who wrote the feature typically wont merge it into master as that will likely result in unforseen errors (we feel it's better if another engineer reviews the code). If the reviewer is unsure about what the code does or why it has been built a certain way then they can collaborate with the original engineer to get a better understanding -> potentially refactoring -> before finally merging into master.
I'm unsure of all the details as I'm not in control of the account but pushing to master triggers a Hudson CI build to kick off and runs our integration tests.
Not that I'm aware of. I've only been on the team since January 2013 so maybe there has been issues that I'm not aware of, but nothing major since my joining has occurred.
No.