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.
We have a company organization. Each repo is owned by the company and is either public or private.
For most larger / private (app) repos we use forks. For smaller public (library) repos we just push directly to company/master and don't use forks, as this aligns with the open source library development work flow.
For smaller (library) repos. (think small node modules) we just push directly as if one person owns the module. Sometimes we do PRs
For larger repos or anything that's deployed 95% of commits go through PRs. The main reason for PRs is so that team members get notifications. We normally immediately merge and deploy the changes.
Most of the time work is done and pushed to fork/master and then we make a PR from fork/master to company/master.
For larger features that we can't deploy immediately or require multiple people/teams to work on the same thing we PR from a fork/feature-branch into company/feature-branch.
Anything that can be deployed easily just gets PR'd into master.
Upto individual engineer. We dislike damaging git history.
Do the work. Push it out to your fork. Make a PR. merge it.
For our public library repos we use travis & testling hooks to run CI. We have not set up CI for private repos yet.
When github goes down work gets slowed down. Private git repos and npm don't play that well together.
We have healthy encouragement of repo creation. If you feel a piece of work belongs in a new repo do it! We also have healthy encouragement of creating public repos. If you feel a piece of works should be open source then do it.
Giving our developers the freedom to publish any code as open source creates a healthy environment for modular code and also encourages our developers to write more tests / documentation. Private repos have significantly less tests / documentation then public ones.