At GitLab we'll tell you to make small merge requests, review and merge often. But in the real world, you have to build a complex feature that requires weeks and thousands of changes.
How can you still have all the advantages of code review, without actually merging a half-baked feature? You make it WIP.
WIP First
WIP, short for Work In Progress, is what you prepend to a merge request in
GitLab, preventing your work from being merged.
Next time you're working on a big feature, create a merge request after the
very first commit and give it a title starting with either WIP or [WIP].
Mention your colleague for a first review, while you keep on working. You have all the power of a merge request, including GitLab CI that checks your code while you work, and no risk of an accidental merge.
WIP mentality
By opening a merge request at the earliest chance, you use one of open source's most powerful tools: the opportunity for feedback.
Your colleagues might not be bothered to do a deep review of unfinished code, but even a glance can catch potential mistakes. Having a second set of eyes thinking about the problems you're solving always pays off.
I encourage you to extend this mentality to your other work, projects and pushes. Push something out early to receive feedback and to be steered in the right direction early on.
At GitLab Inc
At GitLab we prefer people to push things out quickly. We work with WIP merge requests for complex features, like the upcoming Elastic Search implementation.
Meanwhile, we encourage everyone to make decisions and changes as they think is appropriate. By sharing early on, collaboration is almost automatic.
