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.

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?
   We separate in teams, owners can clone and push to the origin.
3. Are engineers allowed to push directly to the official repo? Or must all commits go through a pull request?
   If a repo is owned by another team, engineers must commit through pull requests.
4. Do engineers work on feature branches on the main repo or on their own forks?
   Feature branches must be available on the origin.
5. Do you require engineers to squash commits and rebase before merging?
   Nope.
6. Overall, what is the workflow for getting a new commit into the main repository?
   Merge all feature branches into a integration-branch, run tests, and then, merge with master.
7. What sort of hooks do you make use of?
   Code syntax, conventions and unit tests validation.
8. Are there any ops issues you encountered? (Scaling, unforeseen downtime, etc.)
   Nope.
9. Anything else worth noting?
   For now, everything is working fine

First off, we've been using Git + Github for years now, and have barely deviated from our initial setup

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

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.

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

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.

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

Fast-paced, constant-commit projects use gitflow primarily for the following purposes:

• All new features or non-time-sensitive changes go into feature/ branches
• Small tweaks (i.e. anything that can be resolved in a concise, single commit) are made on develop
• master is tagged & deployed automatically when (1) the test suite passes and (2) there are no db migrations in the release
• Urgent fixes are done gitflow-style via hotfix/ branches which immediately go onto master and develop

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.

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

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 and feature/827-new-admin-theme is totally common)

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

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.

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

1. You or someone else open an issue that needs to be resolved
2. git checkout -b 123-short-description-of-feature or git flow feature start 123-short-description-of-feature
3. Start PR for your branch with either [WIP] or [RFC], depending on if you need help or just approval.
4. Either merge it yourself when someone else OKs it, or the approving party will handle the merge. Everyone's done it all.

What sort of hooks do you make use of?

• Travis
• Internal auto-tagging hook
• NewRelic deployment notifications

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

• Not really. Code base is extremely tested & profiled. Some queries caused bizarre slowdowns, but we reverted immediately, hotfixed it, and redeployed. Ops are rarely needed.

Anything else worth noting?

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.

So to preface, my team is using Bitbucket instead of Github, but I feel these services are close enough in feature sets to provide input to your questions:

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

Yes, we have a single organization that owns all the repos. From what it looks like, all of my team members and I created specific work accounts to join this organization in order to get notifications sent to our work emails.

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

Our team is small and only a few months old right now, so our process is still becoming solidified as time goes on. Right now, no one does a fork from their main project repo to do work.

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

Since we all just clone straight from the repos and there are only a couple of components that have consistent multiple contributors. As such, for the team that I am on, we create a feature branch for each task/work item/bug we work on, do our work, and then submit a pull request before code is committed to master. My goal is to get this process adopted by the other teams since it is very useful and we get code reviews "for free".

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

My team is primarily working from feature branches, but most teams do not from my understanding.

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

No requirements as this time.

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

For my team, we create a feature branch, write the code, run unit tests and jshint, create a pull request, review the request, and then the branch is either reworked to incorporate feedback or merged.

What sort of hooks do you make use of?

I just created hooks this weak for my organization. I have a commit-msg hook to check that a jira task number or [NO-JIRA] tag is included in every commit message. The other hook (i think pre-commit) runs jshint on all my javascript code.

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

None yet for bitbucket.

Anything else worth noting?

We are using hosted Bitbucket.

BBC News

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

There is a BBC News organisation and an administrator account which assigns different users (i.e. BBC staff) access to our private repos.

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

No, engineers pull down the master branch and create a new feature branch.

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

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.

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

Engineers pull down the master branch and create a new branch for each feature they're working on.

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

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.

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

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.

What sort of hooks do you make use of?

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.

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

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.

Anything else worth noting?

No.

We use github enterprise (hosted internally for security/legal/compliance reasons) for all new Java and JavaScript projects, but we use svn for php still. Because we do continuous deployment we have just one main branch per repo that is pushed to production semi-automatically. (someone needs to push "deploy")

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

There is an organization and each repo is owned by the org

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?

Engineers can push to the official repo. We found pull requests a little unwieldy, its also nice to let developers manager their own merges rather than have huge merges when pulls come in. We might change this someday but it works right now.

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

Engineers work on trunk on the main repo unless they are doing something major, using github makes it very easy to rollback something that breaks (we also have a jenkins CI tool that emails and stops deploys when builds fail) For java jenkins fires of a maven build and we use grunt for javascript/css builds.

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

Yes.

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

Git pull --rebase; Git rebase; git push;

What sort of hooks do you make use of?

For js we use a jshint precommit hook just locally. We use the email hooks to handle notifications but everything else is handled in jenkins

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

Not with github. It was down at one point for a few hours but it has been smooth sailing from our pov, no idea how it is going at corp level.

Anything else worth noting?

Amazing how much more productive it is for debs. Unforseen benefit is "internal open source". Code sharing is so much easier than with subversion, other teams in our large company can look at our code, fork it have submitted pull requests, which is awesome! Overall, an incredible way to work. Github issues are great too.

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.