element14 Community
element14 Community
    Register Log In
  • Site
  • Search
  • Log In Register
  • About Us
  • Community Hub
    Community Hub
    • What's New on element14
    • Feedback and Support
    • Benefits of Membership
    • Personal Blogs
    • Members Area
    • Achievement Levels
  • Learn
    Learn
    • Ask an Expert
    • eBooks
    • element14 presents
    • Learning Center
    • Tech Spotlight
    • STEM Academy
    • Webinars, Training and Events
    • Learning Groups
  • Technologies
    Technologies
    • 3D Printing
    • FPGA
    • Industrial Automation
    • Internet of Things
    • Power & Energy
    • Sensors
    • Technology Groups
  • Challenges & Projects
    Challenges & Projects
    • Design Challenges
    • element14 presents Projects
    • Project14
    • Arduino Projects
    • Raspberry Pi Projects
    • Project Groups
  • Products
    Products
    • Arduino
    • Avnet Boards Community
    • Dev Tools
    • Manufacturers
    • Multicomp Pro
    • Product Groups
    • Raspberry Pi
    • RoadTests & Reviews
  • Store
    Store
    • Visit Your Store
    • Choose another store...
      • Europe
      •  Austria (German)
      •  Belgium (Dutch, French)
      •  Bulgaria (Bulgarian)
      •  Czech Republic (Czech)
      •  Denmark (Danish)
      •  Estonia (Estonian)
      •  Finland (Finnish)
      •  France (French)
      •  Germany (German)
      •  Hungary (Hungarian)
      •  Ireland
      •  Israel
      •  Italy (Italian)
      •  Latvia (Latvian)
      •  
      •  Lithuania (Lithuanian)
      •  Netherlands (Dutch)
      •  Norway (Norwegian)
      •  Poland (Polish)
      •  Portugal (Portuguese)
      •  Romania (Romanian)
      •  Russia (Russian)
      •  Slovakia (Slovak)
      •  Slovenia (Slovenian)
      •  Spain (Spanish)
      •  Sweden (Swedish)
      •  Switzerland(German, French)
      •  Turkey (Turkish)
      •  United Kingdom
      • Asia Pacific
      •  Australia
      •  China
      •  Hong Kong
      •  India
      •  Korea (Korean)
      •  Malaysia
      •  New Zealand
      •  Philippines
      •  Singapore
      •  Taiwan
      •  Thailand (Thai)
      • Americas
      •  Brazil (Portuguese)
      •  Canada
      •  Mexico (Spanish)
      •  United States
      Can't find the country/region you're looking for? Visit our export site or find a local distributor.
  • Translate
  • Profile
  • Settings
Community Hub
Community Hub
Member Blogs Firmware Version Control with GitHub part 2: Branch Strategy for Bug Fixes
  • Blog
  • Forum
  • Documents
  • Quiz
  • Events
  • Leaderboard
  • Polls
  • Files
  • Members
  • Mentions
  • Sub-Groups
  • Tags
  • More
  • Cancel
  • New
Join Community Hub to participate - click to join for free!
  • Share
  • More
  • Cancel
Group Actions
  • Group RSS
  • More
  • Cancel
Engagement
  • Author Author: Jan Cumps
  • Date Created: 8 May 2020 12:22 PM Date Created
  • Views 1070 views
  • Likes 5 likes
  • Comments 2 comments
  • tutorial
  • github
  • version_control
  • learning
  • git
  • gitlab
  • github_repository
Related
Recommended

Firmware Version Control with GitHub part 2: Branch Strategy for Bug Fixes

Jan Cumps
Jan Cumps
8 May 2020

image

 

A possible strategy for using GIT and working with branches.

part 2: bug fixes on the released code

image

 

 

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.

image

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.

 

image

 

*1 most likely, the merge process would warn you. But who wants to solve this puzzle at release time?

 

Related Blog
Firmware Version Control with GitHub part 1: Branch Strategy for New Features
Firmware Version Control with GitHub part 2: Branch Strategy for Bug Fixes
Firmware Release with GitHub: Branch, Issue, Pull Request and Project support
Fix a Bug in Production with GitHub: Issue, Branch, Project and (Draft) Pull Request supported + Eclipse Git Plug-in
Break-Fix with GitHub: part two: push bug fixes to the development team
GIT course
  • Sign in to reply

Top Comments

  • Jan Cumps
    Jan Cumps over 5 years ago in reply to fmilburn +2
    Yes/no . I use it for most of my open source projects, as the sole (or 1 of 2) contributor(s), Hosted, for free At work I use it for code that is developed on by several parties, some working on sustain…
  • fmilburn
    fmilburn over 5 years ago +1
    Hi Jan, Do you have thoughts on working directly with GitHub during development of small personal projects Vs. working locally on PC? Not directly related but do you have thoughts on assigning a license…
Parents
  • fmilburn
    fmilburn over 5 years ago

    Hi Jan,


    Do you have thoughts on working directly with GitHub during development of small personal projects Vs. working locally on PC?   Not directly related but do you have thoughts on assigning a license to small personal projects intended to be free for others to use on GitHub?

    • Cancel
    • Vote Up +1 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • Jan Cumps
    Jan Cumps over 5 years ago in reply to fmilburn

    Yes/no image.

    I use it for most of my open source projects, as the sole (or 1 of 2) contributor(s), Hosted, for free

    At work I use it for code that is developed on by several parties, some working on sustain, others on new projects. A mix. Hosted for good money

     

    I don't (want to) work on local PC only Git, without server repo. In that situation, zipping your working folder regularly seems to be simpler...

    • Cancel
    • Vote Up +2 Vote Down
    • Sign in to reply
    • More
    • Cancel
Comment
  • Jan Cumps
    Jan Cumps over 5 years ago in reply to fmilburn

    Yes/no image.

    I use it for most of my open source projects, as the sole (or 1 of 2) contributor(s), Hosted, for free

    At work I use it for code that is developed on by several parties, some working on sustain, others on new projects. A mix. Hosted for good money

     

    I don't (want to) work on local PC only Git, without server repo. In that situation, zipping your working folder regularly seems to be simpler...

    • Cancel
    • Vote Up +2 Vote Down
    • Sign in to reply
    • More
    • Cancel
Children
No Data
element14 Community

element14 is the first online community specifically for engineers. Connect with your peers and get expert answers to your questions.

  • Members
  • Learn
  • Technologies
  • Challenges & Projects
  • Products
  • Store
  • About Us
  • Feedback & Support
  • FAQs
  • Terms of Use
  • Privacy Policy
  • Legal and Copyright Notices
  • Sitemap
  • Cookies

An Avnet Company © 2025 Premier Farnell Limited. All Rights Reserved.

Premier Farnell Ltd, registered in England and Wales (no 00876412), registered office: Farnell House, Forge Lane, Leeds LS12 2NE.

ICP 备案号 10220084.

Follow element14

  • X
  • Facebook
  • linkedin
  • YouTube