Using GitHub inside a company

gistfile1.md

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.

1. What is the primary setup? Is there an organization and each official repo is owned by that organization?
2. Does every engineer have a fork of each repo they're working on?
3. Are engineers allowed to push directly to the official repo? Or must all commits go through a pull request?
4. Do engineers work on feature branches on the main repo or on their own forks?
5. Do you require engineers to squash commits and rebase before merging?
6. Overall, what is the workflow for getting a new commit into the main repository?
7. What sort of hooks do you make use of?
8. Are there any ops issues you encountered? (Scaling, unforeseen downtime, etc.)
9. 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.

Writing about my last company...

What is the primary setup? Is there an organization and each official repo is owned by that organization?

We had three organizations: One for R&D/Engineering, Services and another for Solutions. Each were a different department. I was the resident git "expert" dude, so I had admin over all orgs; but in addition a Director from each department was given admin, along with the principal engineers.

After that, each product team had a number of teams: Principals (write access), Engineers, QA and Read-only. QA and Engineers didn't have access to the same repos and read-only was for product owners, auditors and so-on.

Does every engineer have a fork of each repo they're working on?

Yes.

Are engineers allowed to push directly to the official repo? Or must all commits go through a pull request?

Only principal engineers were able to; for cutting to master and doing other maintenance tasks. Everything else was a PR.

Do engineers work on feature branches on the main repo or on their own forks?

Feature branches on their own forks. The only branches on the upstream repo were "master", "develop" and release-line branches.

Do you require engineers to squash commits and rebase before merging?

This was not a requirement, but was encouraged.

Overall, what is the workflow for getting a new commit into the main repository?

Basically git-flow.

What sort of hooks do you make use of?

No hooks.

Are there any ops issues you encountered? (Scaling, unforeseen downtime, etc.)

GitHub's SSH key issues from a few months back prevented us from deploying on time, but it was an internal release so the effects were not too negative.

Anything else worth noting?

What is the primary setup? Is there an organization and each official repo is owned by that organization?

Yes.

Does every engineer have a fork of each repo they're working on?

No.

Are engineers allowed to push directly to the official repo? Or must all commits go through a pull request?

Yes, everyone are allowed to push anywhere.

Do engineers work on feature branches on the main repo or on their own forks?

On the main repo.

Do you require engineers to squash commits and rebase before merging?

No.

Overall, what is the workflow for getting a new commit into the main repository?

Create a new branch. Do your magic. Merge into test branch. After testing merge into stable branch.

What sort of hooks do you make use of?

Post-receive.

Are there any ops issues you encountered? (Scaling, unforeseen downtime, etc.)

No.

This is how the Autodesk Life Sciences team does things.

1. We have an organization which owns the official repo in Github Enterprise. Each of the contributors has a fork of that repo.
2. We allowed engineers, collaborators, designers, and contractors to fork the repo. We're very permissive.
3. Only a few select engineers on the "core" engineering team are allowed to push directly to the repo, and only if absolutely necessary, usually only for configuration/deployment changes. Everyone is strongly encouraged to work in their own forks and submit pull requests.
4. This varies. We try to encourage working from a feature/bug branch as often as possible, but it isn't strictly enforced, so some folks work on the master branch of their own fork sometimes.
5. Nope. We like the whole history of everything just as it is.
6. Steps go thusly:
   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.
7. We have Rally and Jenkins post-commit hooks, and several pre-commit hooks which (for right now, anyway) are opt-in. I'd like to see these become more widely used.
8. There are two real issues we've run into:
   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).
9. GitHub seems to be lacking three things I'd really like to see in it related to pull requests.
   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.

1 What is the primary setup? Is there an organization and each official repo is owned by that organization?

Yes.

2 Does every engineer have a fork of each repo they're working on?

No.

3 Are engineers allowed to push directly to the official repo? Or must all commits go through a pull request?

Yes, all engineers are able to push directly, but usually we go through a PR.

4 Do engineers work on feature branches on the main repo or on their own forks?

On feature branches.

5 Do you require engineers to squash commits and rebase before merging?

Upto individual engineer, but we seldom squash.

6 Overall, what is the workflow for getting a new commit into the main repository?

Create a feature branch, do the work, push it and make a PR, others review it, merge it.

7 What sort of hooks do you make use of?

Test-hook for CI.

8 Are there any ops issues you encountered? (Scaling, unforeseen downtime, etc.)

Not really.

9 Anything else worth noting?

We at http://justunfollow.com follow these steps.

1. What is the primary setup? Is there an organization and each official repo is owned by that organization?
   Yes, all the repo is owned by organization.
2. Does every engineer have a fork of each repo they're working on?
   Engineers work on branch since commits are everyday. However now folking sounds interesting.
3. Are engineers allowed to push directly to the official repo? Or must all commits go through a pull request?
   We are testing out "pull request". Async code review is a pain. Pull request is really cool when you have small commits.
4. Do engineers work on feature branches on the main repo or on their own forks?
   Engineers work on feature branches.
5. Do you require engineers to squash commits and rebase before merging?
   Yes for one only designated engineer do merging.
6. Overall, what is the workflow for getting a new commit into the main repository?
   Checkout Develop branch > Branch out for new feature > commit > merge to develop > reviewed & merged to master > master is deployed.
7. What sort of hooks do you make use of?
   Not anything great
8. Are there any ops issues you encountered? (Scaling, unforeseen downtime, etc.)
   No
9. Anything else worth noting?
   Wish git was more workflow friendly for code review etc.

Hey Nicholas, I'd be curious what the blog post yields.

What is the primary setup? Is there an organization and each official repo is owned by that organization?

• many remote repos on various platforms (GHE / gitlab / ssh / gitweb) each org tends to own their repo, but for larger repos it's dev-ops managed.
• For the heavier flow/sclae repos used for major releases we use a gitflow branch model vs fork

Does every engineer have a fork of each repo they're working on?

• mostly branches are used but we have folks that used forks, it's up to them really

Are engineers allowed to push directly to the official repo? Or must all commits go through a pull request?

• pushing to the main repo is doing via feature branches (local and remote) and those are then kept up to date and ultimately merged to 'develop' for a release cycle.
• The PMO tracks features for a given release (scope / qa etc. )
• the dev-ops team does a massive feature merge (13+ on average) to create the release branch once all features successfully merge to develop (this is our modification to git-flow, the merges of features to develop are done in batches as they related to a desired scope for release (monthly)
• most of the release generation it is automated and the conflicts are usually relevant (e.g. feature to feature collisions are detected early, then resolved when merging to develop according to a defined strategy)

Do engineers work on feature branches on the main repo or on their own forks?

• main repo

Do you require engineers to squash commits and rebase before merging?

• we recommend: git pull --rebase be set as a default setting but we don't enforce it. generally if you haven't pushed it it's okay to take updates from the remote and rebase your changes on top before pushing.
• We frown strongly upon any notion of force push.

Overall, what is the workflow for getting a new commit into the main repository?

Feature flow:

1. create a feature branch using a custom tool
2. work on the feature
3. test and accept in story / feature branch context
4. stay in sync with upstream develop changes (from releases or hotfixes)
5. batch merge to develop
6. create release branch from develop
7. qa shared features for release on release branch
8. merge release branch back to develop during qa hardening milestones (integration / qa rounds / uat)
9. merge to master
10. tag and deploy artifacts from master

Hotfix flow:

1. create hotfix branch from master
2. checkout open hotfix branch
3. make changes on hotfix -> deploy -> test it
4. merge back to master
5. make artifacts and deploy
6. merge master back to open release branches and develop
7. merge develop back to open features

What sort of hooks do you make use of?

• update hooks track "open" branches and lock deprecated / released branches
• as the release branch hardens to "only p1 phase" we use locks on the release branch and open only for approved / reviewed fixes
• we're prototyping hooks for pre-push checks (not pushing binaries, linting etc.)

Are there any ops issues you encountered? (Scaling, unforeseen downtime, etc.)

• deciding when to version the codebase (pom structure) is an important milestone. generally it's better if you don't "release" (read pop version numbers) until it's tested and signed-off for go-live, but sometimes timelines want to know we're releasing and this becomes a battle with PMO. Try not to touch the code base versions until you absolutely know you're ready to ship. The downstream release version merging can play havoc on open features (esp in CI chains) so you want to limit this impact wherever possible.
• feature branches are cheap, and we tend to like it when they are small in scope and size because there are fewer dependencies and impacts to other features when they are not grouped into one branch
• there is an emerging need to make the batches smaller and the prod releases more frequent
• you definitely want an environment "path to production" for the release track and the hotfix track to be available at the same time so you can do both in parallel if you need to

Anything else worth noting?

• see previous question
• we positively love git
• reverting merges suck, we try to avoid it
• people tend to get creative with branching branches from other branches and we find git-flow really does work for most cases, the one exception being a branch where you can release things to prod via content flow, but then you want to store it in git. it's not a hotfix, but a patch, and it's already live so you really just need a way to update master with the latest prod source of truth so that downstream features can also benefit. we're experimenting with modified hotfix flows for such "syncs" from prod.