Read more

Before you make a merge request: Checklist for common mistakes

Tobias Kraze
June 07, 2013Software engineer at makandra GmbH

Merge requests are often rejected for similar reasons.

Illustration money motivation

Opscomplete powered by makandra brand

Save money by migrating from AWS to our fully managed hosting in Germany.

  • Trusted by over 100 customers
  • Ready to use with Ruby, Node.js, PHP
  • Proactive management by operations experts
Read more Show archive.org snapshot

To avoid this, before you send a merge request, please confirm that your code ...

  • has been reviewed by yourself beforehand
  • fulfills every requirement defined as an acceptance criterion
  • does not have any log or debugging statements like console.log(...), byebug etc.
  • has green tests
  • has tests for new features
  • has been manually tested in the browser
  • has no missing translations in the UI
  • has no ugly UI changes (long content breaking out of boxes, elements without margins, etc.)
  • works with lots of records without triggering a million queries or loading the world into memory¹
  • sorts all lists (indexes, select dropdowns, ...) by either sorting in the database or using natural_sort in Ruby
  • paginates long index lists
  • has all necessary database indexes to speed up foreign key look ups and commonly used queries
  • if it adds any migrations, takes care of existing records
  • if it creates any new tables, adds created_at and updated_at timestamps (t.timestamps)
  • if it makes major changes, has updated the README as appropriate

Please also add screenshots of any changed UI.

¹ This should be verified in a private browsing window as you might not notice any issues on cached screens (E-Tags etc.)

Posted by Tobias Kraze to makandra dev (2013-06-07 15:03)