A possible strategy for using GIT and working with branches.
part 2: bug fixes on the released code
Fixing Bugs in Released Code while Development is Going On
This is a common challenge in for any project that has active development while there is a supported version out there.
How do I fix bugs in my released code - and avoid that the fix is overwritten once the development of new features is complete?
In part 1 I reviewed a branch strategy for working on developments, while keeping the released code (master branch) stable.
I use a development branch to work on new features. That development branch is a clone from production at a given time in the past.
Even though we say that the master branch is stable, it actually isn't. We can have bugs or urgently requested changes.
This post tries to deal with that: allow bug fix style changes in the master while working on a new developments in parallel.
Bug Fix Branch
If you saw the previous post, I used a feature branch to manage single feature changes during development.
A bug fix branch is virtually essential. Fixing a production code bug is similar t handling a single change in a development.
The difference here is that the source and destination of this feature branch is the master branch - and -see later - that we don't want to loose that fix when the development branch is released later on.
The bug fix branch is created identically as the feature branches in the previous blog, except the branch we start from is the master.
Then a short lived feature branch is created onto that, where the bug fixer can be developed.
The keen eye can see that the process is identical to that of part 1, where we created a feature branch for new developments.
That's right. Except that - as seen before - the source and destination is master.
Once the bug is fixed and tests pass, the contributor creates a pull request to the master.
Approval of the code is the same as for a development branch. Admin reviews and approves the pull request, and merge into master happens.
Then here's something extra:
Sync Bug Fixes to Development to Prevent Regression
If you'd just accept the bug fix in the master branch, you introduce a problem.
The bug would be fixed and you can send out a new release. But the development branch - a clone of your master branch - still has the bug.
If you'd merge your development branch with master at release time, you would overwrite all that hard work that the bug fixer did*1.
That's why, when accepting the bug fix, the admin should also send (sync) that fix to the development branch.
There are several ways to do this (as always in Git).
My sugestion is to create a pull request from master to development, right after the pull request is created.
Then send a message to the development branch owner (if you have an unsuccessful open source project, that's also you).
They can then take in that change, and deal with any impact on the development work.
In my job, where I manage the development branch of a project, I check for newly accepted pull requests in the master daily.
Then I create a pull request in the development branch and accept it too. The policy is set to allow that.
Then I mail the development managers that a new production sync happened, with a list of the changed files.
This is a supporting activity, because in parallel we run a shared forum where we share what objects both production support and projects are working on. A sync mail should never come as a surprise.
The sync is not a complex thing. It's a repeatable action.
You can create a script for that. I've made one that performs this in a few seconds:
- Clone development branch
- Then create a new development_sync branch.
- Pull in the latest production changes from master.
- Commit those to the new development _sync branch
Then create a pull request (in GitHub) from development_sync into development.
Then accept that pull request and delete the production_sync branch
Then inform the development team.
*1 most likely, the merge process would warn you. But who wants to solve this puzzle at release time?