rubocop-github is a house style, not just a config file

What the gem actually contributes to a RuboCop run

rubocop-github is described as recommended RuboCop configuration plus additional Cops for use on GitHub open source and internal Ruby projects, and it is also the home of GitHub's Ruby Style Guide, held in the repository as STYLEGUIDE.md.

Two distinct things travel in one gem. The first is a set of configuration files, config/default.yml for generic Ruby rules and config/rails.yml for Rails-specific rules and cops, which is what a project inherits. The second is a set of custom cops written for this project, all of them under the GitHub namespace in lib/rubocop/cop/github, which is what a project requires.

The distinction matters because RuboCop's own default configuration already defines a style, and a shared house style is a different proposition from a linter. The value here is that a large Ruby organisation has already settled most of these arguments, and a new project can take that decision as a starting point rather than relitigating it. The counterargument is equally plain: a config file is opinionated, and adopting one means adopting every rule in it.

Inheriting the config versus requiring only the cops

The documentation gives two routes, and they are not equivalent.

The first adds the gem and its companion gems to the Gemfile:

  gem "rubocop-github", require: false
  gem "rubocop-performance", require: false
  gem "rubocop-rails", require: false

The `require: false` flag matters. The gem is a configuration and cop provider, not a library your application loads at boot, so requiring it from the Gemfile would pull it into the runtime for no reason.

The inheritance declaration then pulls in the whole rule set:

  # .rubocop.yml
  inherit_gem:
    rubocop-github:
    - config/default.yml # generic Ruby rules and cops
    - config/rails.yml # Rails-specific rules and cops

The second route skips the rules and takes only the custom cops:

  # .rubocop.yml
  require:
    - rubocop-github  # generic Ruby cops only
    - rubocop-github-rails # Rails-specific cops only

That second form is the one to pick when a project already has an agreed style. It keeps the GitHub-specific checks and leaves the stylistic rules where the project put them.

The accessibility configs that left the gem

One part of this gem has already moved. The documentation points out that config/accessibility.yml and the GitHub/Accessibility configs are no longer here, and that they have been moved to a new gem, github/rubocop-rails-accessibility.

This is worth noting because config inheritance is not additive across gems in the way people expect. A project that upgraded and suddenly lost its accessibility checks did not experience a RuboCop bug, it experienced a package boundary moving. Anything pinned to an old rubocop-github release still gets the accessibility configuration from that release, and anything on a recent release has to declare the new gem explicitly.

The same lesson applies to rubocop-performance and rubocop-rails in the Gemfile example. Those are separate gems with their own release cycles, so a rule set that looks stable in one project can differ from the same project three months later without anything in the rubocop-github version number changing.

DisabledByDefault turns the config into a menu

For projects that want the GitHub cops without the GitHub style, the documentation points to the DisabledByDefault option under AllCops. Setting it to true in a project's .rubocop.yml disables all cops, and individual rules are then switched on explicitly with Enabled: true.

This is the granular path through the whole configuration, from this gem and from a project's own configs, and it changes the character of the gem from a preset to a catalogue. A project can cherry-pick the handful of GitHub cops that encode real policy, such as a rule about a forbidden method, and leave the naming and layout opinions out.

The trade-off is that this puts the work back on the adopting team. Turning everything off and turning a subset on means reading the list of available cops, which is exactly the work the inheritance declaration was supposed to avoid. The option is right for a mature codebase with an established style, and wrong for a new project that wants a defensible default.

Running the tests, and the frozen path for old RuboCop

The gem's own development setup uses Bundler and Rake:

bundle install
bundle exec rake test

The repository supports that with a Gemfile, a Gemfile.lock, a Rakefile, a rubocop-github.gemspec and a test directory, and it lints itself through a .rubocop.yml and a .ruby-version at the root. The CI setup is visible in the badges: separate workflows for test, build, lint and release, each pointing at a workflow file in .github.

The compatibility note is the part that catches people out. For a RuboCop version below 1.0.0, the documentation says to use rubocop-github version 0.16.2 and read the README from that version for the details. That is an honest way to describe an awkward gap, and it means the older line is frozen rather than maintained. A project stuck on an old RuboCop is not blocked, but it is also not receiving fixes from this gem.

The cops, the style guide and the directory layout

The custom cops live in one place, lib/rubocop/cop/github, and the documentation states plainly that all cops are located there. A GitHub namespace rather than the standard RuboCop department namespaces is a signal about what these cops are: they encode house decisions rather than general style theory.

The repository layout supports that reading. There is a config directory holding the shipped configuration files, a guides directory, the STYLEGUIDE.md at the root, and a script directory alongside lib. The style guide being a first-class file, rather than a wiki page, means the reasoning behind a rule can be read next to the rule, and reviewed when a rule changes.

The alternative to all of this is running RuboCop with its own defaults and no inherited config. The difference in approach is what you are buying: the defaults are a general community compromise, while inheriting this gem gives you the configuration of a large Ruby shop, including the specific rules that came out of its own code review habits. The price is that you inherit its opinions, and the GitHub namespace cops only make sense if you accept the GitHub view of what those checks should be.

MIT terms, fast releases, and a version number to pin

The gem is released under the MIT Licence, and it is published on RubyGems as rubocop-github. The repository is not archived and the last push was on 2026-10-22, so the work is current.

The release cadence is the part that has a practical effect. The three most recent versions are v0.29.0 published on 2026-10-02, v0.28.0 on 2026-09-30 and v0.27.0 on 2026-03-13. Two releases three days apart and a six month gap before that is a project that ships when something needs shipping rather than on a schedule.

The version number is the other signal. This gem is still at 0.x, which in Ruby convention means the public interface is not yet treated as stable, and that matches what the documentation does: it tells you to pin to 0.16.2 for old RuboCop, and it documents a config file that moved to a different gem between releases. Adopting the latest version is reasonable; depending on the specific contents of config/default.yml without pinning is not, because a dependency bump can change the rule set under a project that never asked for the change. Pinning the exact version in the Gemfile keeps the style stable, and MIT terms keep that usage free of licensing questions beyond attribution.

Editorial conclusion

rubocop-github fits a Ruby or Rails team that wants a coherent style without arguing about every cop, and the inherit_gem declaration is the cheapest way to get there, while the separate require path suits a project that already has its own rules and only wants the GitHub cops. It does not fit a codebase pinned to RuboCop below 1.0.0, where the documentation points you at the frozen 0.16.2 release instead. Before adopting it, read config/default.yml and config/rails.yml against your own .rubocop.yml, confirm that the accessibility rules you relied on now live in the rubocop-rails-accessibility gem, and pin an exact version, since the last three releases were 0.27.0, 0.28.0 and 0.29.0.

Frequently asked questions

Official sources

1. github/rubocop-github on GitHub
2. License: MIT
3. Project website
4. README
5. Releases