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.

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.