Sometime back we faced a peculiar problem in our project where we have to fix some issue introduced due to a merged branch. To explain this problem first I've to explain the way we manage branches. As we entered in the maintenance mode of project there was a dire need of fixing issues and working on change requests in isolation. Whenever we need to fix an issue we cut a issue-branch out of main branch fix that issue in isolation and after verifying and making sure the issue is fixed we merge that issue-branch back in main branch. The issue we faced with the approach is that after merging an issue branch with the main branch sometimes we came across some regression bugs due to the issue branch. There were two possible solutions to overcome the problem.
First solution is to fix the issue in issue branch and merge the issue branch again with master. This solution can work but the problem with this approach is that till the time you haven't fixed the issue introduced due to issue branch and merged it back with master branch you can not create a new issue-branch and much bigger problem is you can't release.
The second solution is if we can somehow revert the merge of issue branch with main branch and then fix the issue in issue-branch, after that merging the fixed issue branch with the main branch. This approach seems to be straight forward and more logical. Git comes up with a cool command git-revert which can revert existing commits and even revert merge of another branch. I'll talk about the solution in the next blog ;)
First solution is to fix the issue in issue branch and merge the issue branch again with master. This solution can work but the problem with this approach is that till the time you haven't fixed the issue introduced due to issue branch and merged it back with master branch you can not create a new issue-branch and much bigger problem is you can't release.
The second solution is if we can somehow revert the merge of issue branch with main branch and then fix the issue in issue-branch, after that merging the fixed issue branch with the main branch. This approach seems to be straight forward and more logical. Git comes up with a cool command git-revert which can revert existing commits and even revert merge of another branch. I'll talk about the solution in the next blog ;)
We recently started using continuous integration. In that – you should always take the changes from trunk/master to your issue/development branch every day (we call it rebase) and fix the issues in issue branch, if there is any, due to rebase (and you work further once you have fixed the rebase issues – every day). And once you are done with bug fix or CR implementation you can safely merge back the changes to trunk (master branch) . This way there will not any discrepancies and additional merge issues since the code is in sync with trunk.
ReplyDeleteAs per your approach, you are not rebasing it everyday but you merge back the changes and then rebase it and then resolve the issues which can be quite cumbersome and dangerous as you might miss something when you have to fix many things but if you do it on per day basis you minimize the impact.
Hi Prakash,
ReplyDeleteYou are completely right, but the problem that I was talking about has a bit different context. The prob was that if u have merged an issue branch having some issue with master branch and you have to revert that merge thing, this blog is about this problem.
As far as merging master branch with issue branch we also do it frequently infact more then once a day.