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
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.