From no workflow to gitflow to pull requests. Here’s our story…
Initially, we don’t use Git for our projects. Around 2010, SVN is our main source control / versioning ( aside from Dropbox and USB Drive transfer 🤘 ). After we grow into several people working in the same project, several discomforts occurred and we decided to adopt Git around 2013.
As usual, the first time is a mess. Several projects have messed up git history that made tracking and merging painful to do. We don’t have any consensus on how to divide branches, or any decent workflow to implement. People just do commit and push as they like. Finally in late 2014 we decided to adopt gitflow into our workflow. Things got better real quick. We know what to track, who’s doing what and the current branch status.
But there are still some pain points that we encounter, especially regarding our junior developers. To make a clear and readable branch history, sometimes squash / rebase / rewrite remote history is necessary. And since we don’t protect the develop / master branch sometimes the history got messed up real quick.
In 2016 we’re starting to actively release our own libraries and little by little using Pull Request as a way to manage our open source library updates. And surprisingly in 2017, several of our developers suggested that we use Pull Request workflow to replace gitflow.
To be honest, I was against Pull Request at first. The main reason is that it might introduce bottleneck especially when the reviewer is busy. Deciding the workflow is also requires some discussions ( should we use multiple repo? or one repository with protected branches? how to name branches? etc. ). But in the end after weighing the benefits vs drawbacks I decided to implement Pull Request workflow in some of our projects.
The result is incredible. The benefits totally outweigh the drawbacks. Let’s discuss them in details.
Benefits of Pull Request Workflow
- Clean git history by using pull request, we can easily squash those redundant / unimportant / unclear commits before merging into main branch. This is enforced by our protected branch policy. Only the lead / captain can merge into main branch. Other developers are free to do whatever they want in their branches
- Meaningful git history we used to neglect this one aspect but turns out this is more important than we think. By adhering with our branch naming convention, all pull requests and merge(s) becomes easier to read and provide features / fixes history. In the end, your git history can be a tools to track productivity and/or project velocity.
- Remote code review process before pull request, we did code review face to face either by pair programming or code presentation session. Using pull request as our workflow, code review can be done before pull request is merged. This enable smooth code review process, even while doing remote work.
- Better software quality making pull request means that the feature need to be approved by captain / lead and QA / QC. Before pull request, all features and fixes can be merged to main branch hence updating staging server without the knowledge of QA / QC. This makes testing harder because there is no way to ensure the staging server state. Doing pull requests means that staging server state will only be updated after all changes are approved by lead & QA. This ensures that all codes in our staging server is already inspected by several stakeholders hence better quality.
Drawbacks of Pull Request Workflow
- Long review process especially when the captain / lead is busy. otherwise, all is well.
- Time / process overhead there are some complaints that doing pull request resulting in more process to be done. You need to create a pull request in browser, adding comments & change logs, waiting & fixing for feedbacks etc. Sometimes an idle time happens because the developer is waiting for approval and cannot start working on new branch. We discourage working on parallel branches because we believe that focus is important.
Even though we successfully implement pull request workflow in some of our projects, a detailed guide is necessary to ensure that no redundancy / misconception happened. After several discussions we came up with this workflow conventions. Feel free to give your feedbacks and inputs on this matter!
After adopting pull request workflow with additional conventions above, I definitely can say that our projects have been better overall. There might be some problems here and there, but the benefit is really apparent. I suggest that you try to use this approach at least for comparison with your current workflow.
Cheers
disclaimer : This post is based on my personal experience while working with Flipbox. Our daily activities and projects is revolving around mobile apps & (sometimes) websites for clients. Those points and suggestions might not apply in a different circumstances.
Top comments (0)