Merge Requests

With the Git Flow methodology we use, normal development work takes place in feature/whatever branches. When these branches are code-complete and ready for testing, they should be merged in to the develop branch.

Merging to develop should involve a code review, unless a feature is incredibly minimal, or needs to be launched unusually quickly. Default to requesting a code review.

We do code review through GitLab Merge requests (Or GitHub Pull Requests, for older projects). A Merge Request is a way to say “I have code over here which I want to be merged in over there.” Most commonly, that means you have code in a feature branch which should get merged develop, or you have a bunch of QA’ed code in develop which you want to merge into master for production deployment.

Here is the GitLab documentation for basic reference:

Even if you are used to using an MR workflow, here is what you need to know about ours.

  • MRs go with Basecamp ToDos or Asana Tasks. They should be associated completely and exclusively with ONE Task/ToDo. The Task/ToDo should link to the MR containing the relevant code changes. When you create a MR, comment in Basecamp or Asana with a link to it. Ideally, grab the basecamp Task/ToDo link and make it a part of the MR content.
  • Not all Tasks/ToDos require a MR. Use your discretion. But code review as often as possible.
  • Basecamp/Asana assignment is canonical. If the MR is assigned to you but the Task/ToDo is not, obey the Task/ToDo.
  • Make PRs tight and neat. No jumbo reviews please. If the Task/ToDo is too broad to allow for a tight PR, break the Task/ToDo into a sub-group or sub-list and inform the project Artisan.