public
Created

Using GitHub inside a company

  • Download Gist
gistfile1.md
Markdown

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. Yes
  2. No, we do not fork but we clone our central repo
  3. All code must go through a pull request
  4. Yes all engineers work on feature branches on the main repo
  5. We squash when we merge into a our master / prod branch
  6. JIRA Ticket -> create a branch of main branch -> pull request -> code review -> merge squash into prod branch -> deploy
  7. None right meow
  8. nope
  9. works like a charm.
  1. yes
  2. branch for internal, fork for vendor. pull requests are always used.
  3. pull requests only. tech lead manages this.
  4. answer in #2
  5. usually if its coming into a dev,stage or master branch
  6. pull requests are reviewed by a tech lead and merged in once dev has completed any necessary changes.
  7. builds for dev and stage that go through jenkins
  8. downtime is our biggest concern. ghub seems to deal with attacks quite often this can cause problems at times
  9. scripted deploys with capistrano, fabric or other means are key in combination with github to manage code promotion
  1. We have a "BankSimple" org and then projects inside of that.
  2. No, some tried it, but it ended up being a huge pain to pull down other people's code to try it out. Instead we use feature branches like username/projectname or, me personally, projectname/ticket.
  3. Depends and it's up to the coders discretion. We expect our engineers to be good enough to know if they should have someone review their code or not. I'd say the majority of commits come through as a PR, but not all. Plus, having to review changes that are just a few lines kills everyone's flow and you shouldn't be hiring engineers if you can't trust them to make simple changes.
  4. Feature branches. Also, see #2.
  5. We don't require it. Personally, I don't like rebases, but most of the team does so they do. None of us squash. I hate squashes. They destroy history and make git bisect impossible. If you find a bug and bisect to some squash with a 1000 lines, good luck tracking that down very fast.
  6. Git pull, git branch feature/ticket, make changes, commit, git push to feature/ticket, send PR, if approved merge.
  7. None right now.
  8. Not really. 9 If you're behind a firewall / need a VPN, you can't reply to tickets via email. You will get notified of some bug or serious issue, but will have no way of replying until you're at a computer on the VPN.
  1. Each engineer is part of one or multiple organizations. Each repo is then owned by an organization. Tech leads (and some trusted others) get owner access to organizations. Teams get access to repos.
  2. Every engineer forks.
  3. Engineers are asked to submit changes through a pull request. Those are peer-reviewed and merged after approval.
  4. Engineers work on local feature branches on their fork and those are merged into the main repo via PR.
  5. No squash/rebase requirement.
  6. Commit is made on local repo on feature branch. Branch is pushed to engineer's remote fork. Pull request is made to merge engineer's branch into main repo main branch.
  7. No hooks using GitHub Enterprise. Engineers may have their own local hooks. This is probably a point where we could improve.
  8. No ops issues with GitHub Enterprise yet.
  9. There are only a few teams using GitHub Enterprise. Most of the rest of the company uses Perforce. The teams using GHE are mostly the Web-based teams. We made the transition from hosting our own git server to GHE about November of 2012. Some like it. Some don't. The biggest gripe seems to be the code review process. We used to use Code Collaborator, and many seem to have liked that better. I, personally, couldn't care less. I like the convenience of using one tool. But I do think there are things we could do to better utilize GHE (hooks being one). We're fairly new with it, but we are learning.

So for the longest time Yammer was using public github with an org for private repositories. We recently setup GHE internally and we're in the process of migrating many repos there. There are probably several reasons, but a big one is that it became difficult to manage some things that needed to be secret. We needed to be more careful about what things ended up on servers that we don't own.

1) We have repositories all over the place. All production repos are under the yammer org, either on github.com or GHE. We have internal projects, personal projects on people's private accounts, a "third party" account where we maintain forks of public open source stuff. I don't think it would buy us much to have a super strict system. It all boils down to a url and the right access.

2) Engineers can fork if they want. But historically we've been fine having a single repo and having project teams use feature branches. This has been fine even as we've scaled up to our current size. The only real downside is a proliferation of old feature branches. But that's sometimes good for historical context. For other reasons, engineers at yammer are exploring using a pull request model right now. More on that below.

3) Yes, all engineers are empowered and encouraged to push to master. We trust engineers and we value engineering velocity. It doesn't mean people's code doesn't get checked. Communication within project teams is very high. But it's an informal process rather than a thing that limits velocity.

There is a little more of a barrier if you are working in a codebase outside of your usual area (though still informal). For instance, as a front-end engineer, I may find myself working one of our back-end JVM services. I'd know better than to ship something to master there because I'm not as familiar with things. So I'd make sure my feature branch got reviewed by an engineer from our core services team. Once that person have the thumbs up, I could merge that branch into their master.

4) See #2. Lots of feature branches. But I just realized that other engineering teams at yammer may have a slightly different workflow. People work however they want as long as the people in their immediate sphere all loosely agree. I haven't thought a lot about it, but I don't see the immediate benefits of everyone having forks. Feels like it would be a lot of maintenance for not a lot of gain. I'd be interested to hear other thoughts though.

One big topic right now is introducing a better code review workflow at yammer. As I said, right now this happens in an ad hoc way, and some people want to streamline how things are done to make it faster and more convenient. We have people exploring the pull request workflow. But we still have an aversion to putting in limiting gates. So we would be resistant to a process where you couldn't ship unless someone accepted your pull request. Instead a PR is just a convenient way of packaging up a related set of commits so you can have someone else review them. Some people might instead used squashed commits or just point reviewers at a feature branch on github. The actual process is less important than being able to use the nice github interface for commenting on and discussing code.

The biggest annoyance with this is that yammer folks like all discussions to be in yammer. But now we have interesting conversations that happen in github because the context is better. I'm hoping some kind of integration makes that story better soon. Yammer should be in everything ;)

5) We don't require it. Squashing and rebasing are a hotly debated topic internally. My team has a simple branch and merge workflow. Other teams have people who love rebase and squash. At the end of the day, what we care about is that the right code gets shipped. And each engineer is responsible for shepherding their changes through to production. So having these competing workflows hasn't really been a large enough issue for us to make a rule either way. I don't know if Yammer is special here in some way. I'd be interested to hear other stories. One thing that I think is relevant is that we don't often find ourselves wanting to roll back giant merges. That's frequently cited as a case for when a strict git workflow can come in handy. We generally don't find that to be a huge pain point though.

I've officially bowed out of the "what's the best git workflow" debate. But I'm fine talking through pros and cons of various approaches. I've tried several at this point. You should pick the one that suits your team the best or supports your engineering goals the best. Or just let people sort it out on their own.

6) If it's a small change, just do it. Write a test, make sure it passes, check it in your dev environment, ship it. Larger changes go through feature branches. Feature branches should be kept up to date by merging or rebasing in master pretty frequently (daily). Our automated test systems should always be able to run off of branches. We're not quite there yet with remote CI. But you can always run test suites locally against branches. Again, you can have other people review your changes if you think it's warranted. This includes other engineers or QA.

If you're on support, you probably own the changes and so you just merge/squash into master. If you're on a project team, then you coordinate with the team for when those changes should ship. You may have a long running feature branch. You may have a separate project branch where engineers on the project team merge and integrate their various changes. Once the project changes are tested and QAed locally as much needed, then merge/squash to master. Master is treated as "stable and shippable". Once you push to master, you should expect that those changes could be in production without you knowing it.

The important thing here is that engineers shepherd their changes through the system by making sure all interested parties stay informed. Product managers and QA know when things are shipping in the next release. Other teams get a heads up when major changes are pushed into a codebase. We try to substitute good communication for strict process here. It's worked pretty well so far.

7) Not sure. The front-end team doesn't use any right now. But we're considering pre-commit hooks for linting.

8) With github? I'm sure there are stories here that I'm not familiar with. I can try to get info from others at Yammer. But I know it pays to decouple deployments from the network. Pull down local branches before deploy time. Make tarballs that get distributed by scripts. Relying on the network (even your own internal one), for a deploy going smoothly will probably bite you at some point. It's a tradeoff between convenience and reliability.

9) The main thing I want to leave you with here is to think hard about what putting strict processes in place is supposed to buy you. Only use them when they pay the bills. Otherwise just let people use their judgment. And if people have bad judgment, that's not a problem that can be fixed with process.

Here's an example. For most of my tenure on the front-end team at yammer, we used the git-flow model. It worked well for us as a team because we had lots of people making changes and we wanted low friction to pushing those out. But we also had a weekly deploy process that meant we couldn't just ship to master whenever we wanted. So git flow's split between develop and master branches fit nicely. No other team at yammer used the git flow model. We got teased a bit, and we had to educate people on how to interact with our codebase. But it worked for us.

But today yammer is continuing to move towards a continuous deployment model. We do releases more often and we've refactored our front-end codebase structure so that it's more manageable. After taking stock of all of these things, we realized that the git flow model might be holding us back at this point. We want to ship to master more quickly so changes can be picked up by the very latest release. And managing the gap between develop and master was becoming a pain rather than being helpful. Git flow had gone from a useful process that helped us maintain speed despite a slower release process, to a hinderance that kept us behind as our release process caught up. The team talked about it and agreed. So we ditched it. We now have release branches and master. And everybody's happy.

I hope all of this is helpful. Having an excuse to write this all down was cool. I can provide more details if you're confused or curious about anything. I'm sure there are gaps here that we could be doing much better. But this stuff is on a continuous improvement curve at yammer.

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

We have a company organization. Each repo is owned by the company and is either public or private.

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

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.

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

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.

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

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.

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

Upto individual engineer. We dislike damaging git history.

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

Do the work. Push it out to your fork. Make a PR. merge it.

7) What sort of hooks do you make use of?

For our public library repos we use travis & testling hooks to run CI. We have not set up CI for private repos yet.

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

When github goes down work gets slowed down. Private git repos and npm don't play that well together.

9) Anything else worth noting?

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.

  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?

Please sign in to comment on this gist.

Something went wrong with that request. Please try again.