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