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 Asana Tasks. They should be associated completely and exclusively with ONE Task. The Task 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 link and make it a part of the MR content.
- Not all Tasks require a MR. Use your discretion. But code review as often as possible.
- Asana assignment is canonical. If the MR is assigned to you but the Task is not, obey the Task.
- Make PRs tight and neat. No jumbo reviews please. If the Task is too broad to allow for a tight PR, break the Task into a sub-group or sub-list and inform the project Strategist.