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 online protection

Rails Long Term Support

Rails LTS provides security patches for old versions of Ruby on Rails (2.3, 3.2, 4.2 and 5.2)

  • Prevents you from data breaches and liability risks
  • Upgrade at your own pace
  • Works with modern Rubies
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)