title: Git branching strategy integated with testing/QA process
body: <p>Our development team has been using the <a href="http://nvie.com/posts/a-successful-git-branching-model/" rel="noreferrer">GitFlow</a> branching strategy and it has been great !</p>
  
  <p>Recently we recruited a couple testers to improve our software quality. The idea is that every feature should be tested/QA by a tester.</p>
  
  <p>In the past, developers work on features on separate feature branches and merge them back to the <code>develop</code> branch when done. The developer will test his work himself on that <code>feature</code> branch. Now with testers, we start asking this Question</p>
  
  <blockquote>
    <p>On which branch should the tester test   new features ?</p>
  </blockquote>
  
  <p>Obviously, there are two options: </p>
  
  <ul>
  <li>on the individual feature branch</li>
  <li>on the <code>develop</code> branch</li>
  </ul>
  
  <h2>Testing On Develop Branch</h2>
  
  <p>Initially, we believed this is the sure way to go because:</p>
  
  <ul>
  <li>The feature is tested with all other features merged to the <code>develop</code> branch since it's development started. </li>
  <li>Any conflicts can be detected earlier than later</li>
  <li>It makes the tester's job easy, he is only dealing with one branch (<code>develop</code>) at all time. He doesn't need to ask the developer about which branch is for which feature ( feature branches are personal branches managed exclusively and freely by relevant developers )</li>
  </ul>
  
  <p>The biggest problems with this is:</p>
  
  <ul>
  <li><p>The <code>develop</code> branch is polluted with bugs. </p>
  
  <p>When the tester finds bugs or conflicts, he reports them back to the developer, who fixes the issue on the develop branch (the feature branch were abandoned once merged ), and there could be more fixes required afterward. Multiple subsequence commits or merges (if a branch is recreated off <code>develop</code> branch again for fixing the bugs) makes rolling back the feature from the <code>develop</code> branch very difficult if possible. There are multiple features merging to and being fixed on the <code>develop</code> branch at different times. This creates a big issue when we want to create a release with just some of the features in the <code>develop</code> branch </p></li>
  </ul>
  
  <h2>Testing On Feature Branch</h2>
  
  <p>So we thought again and decided we should test features on the feature branches. Before we test, we merge the changes from the <code>develop</code> branch to the feature branch ( catch up with the <code>develop</code> branch ). This is good:</p>
  
  <ul>
  <li>You still test the feature with other features in the mainstream</li>
  <li>Further development ( e.g. bug fix, resolving conflict ) will not pollute the <code>develop</code> branch;</li>
  <li>You can easily decide not to release the feature until it is fully tested and approved;</li>
  </ul>
  
  <p>However, there are some drawbacks</p>
  
  <ul>
  <li>The tester has to do the merging of the code, and if there's any conflict (very likely), he has to ask the developer for help. Our testers specialize in test and are not capable of coding.</li>
  <li>a feature could be tested without the existence of another new feature. e.g. Feature A and B are both under test at the same time, the two features are unaware of each other because neither of them has been merged to the <code>develop</code> branch. These means you will have to test against the <code>develop</code> branch again when both of the features are merged to the develop branch anyway. And you have to remember to test this in the future.</li>
  <li>If Feature A and B are both tested and approved, but when merged a conflict is identified, both of the developers for both features believe it is not his own fault/job because his feature branch past the test. There is an extra overhead in communication, and sometimes whoever resolving the conflict is frustrated. </li>
  </ul>
  
  <hr>
  
  <p>Above is our story. With limited resource, I would like to avoid testing everything everywhere. We are still looking for a better way to cope with this. I would love to hear how other teams handle this kind of situations.</p>