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.
This is how the Autodesk Life Sciences team does things.
a. Fetch from main repo master branch to your fork's master branch.
b. Resolve merge conflicts. (Should be none if you're doing this right.)
c. Create a new feature/bug branch.
d. When finished, submit a pull request from your fork/branch to main repo/master.
e. Engineers review the code.
f. Once reviewed, one of the engineers merges the code into the master branch automatically or manually if required.
a. Merging a pull request with lot of commits is a pain. Github can't display all the files, and it's quite tedious to go through all of the commits individually. Not every engineer is comfortable making small commits and pull requests, and the large ones don't have an elegant solution for review.
b. The workflows for Git and GitHub are very foreign to many engineers used to centralized version control systems such as Perforce, SVN, ClearCase, and the like. Trying to coerce git's decentralized nature into a centralized system doesn't really work, but the mental barrier to fully accepting the different workflow Git implies is a hard one for many to overcome. This often prevents us from utilizing Git and GitHub to its fullest (see prior comment about making small commits).
a. The ability to perform a side-by-side diff comparison, optionally with common ancestors. Git can do this, so it seems unreasonable to me that GitHub can't.
b. Large pull requests with many commits shouldn't be suppressed. Instead, they should be paginated, allowing the ability to paginate through the entire pull request. Difftools and merge tools locally can do this, so this is a technical consideration GitHub should be able to overcome.
c. It would be really useful to have the ability to require a certain number of people to review a pull request before it can be merged in, specified by the repo/organization owner. For example, the pull request can't be merged in until at least two of the members of the Owners team have approved it. Or, alternately, require the submitter of the pull request to specify who must review the pull request before it gets merged. Something similar to these.