Firmware Version Control with GitHub part 1: Branch Strategy for New Features

RE: Firmware Version Control with GitHub part 1: Branch Strategy for New Features

Workshopshed — Wed, 12 Aug 2020 20:22:02 GMT

Having spent just over 2 months now using git flow (the branching model, not the software) pretty much daily at work. I can conclude that it mostly works. We commit and merge code daily and release multiple times per week to production. Not as fast as some places but it seems to be mostly working.

Git flow works really well when the changes made in the different features don't affect the same parts of the code. One strategy for dealing with releasing several overlapping features at the same time is the release branch approach.

It works really well when you submit the features to dev and then to master quite frequently.

Things that will cause you grief:

If two of your colleagues both decide to do a big rewrite at the same time then you can have a nightmare merging them back together. For that case a strategy of restricting to one person doing radical changes or pair programming can work.

It does not work so well when you've got automated tools generating files that are source controlled. If possible, don't include those files if possible let them get regenerated by your build pipeline.

If you've got a few people in your team and are working on multiple features, I can also recommend a branching visualiser tool, we use gitkraken but there are plenty of others about.

RE: Firmware Version Control with GitHub part 1: Branch Strategy for New Features

Andrew J — Wed, 12 Aug 2020 19:23:26 GMT

Following on to wrap up (I started on the false assumption you were describing the use of gitflow without actually mentioning it!)

gitflow follows the same branching strategy as you describe here which isn't surprising as it originates from the same place. By default, it isn't geared up to use Pull Requests as you do, and I think that could be a concern for many development cooperations. Not so much for hobbyists who could keep things simple of course!

Instead of Pull Requests, gitflow uses a concept of 'Finish', e.g. (once the release changes are committed):

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:3ef06e6b-9b7d-4651-b12d-db8be7f5e991:type=text&text=git+flow+finish+release%2FRelease1.0.1]

This just wraps a number of git commands into one operation: e.g. for a release branch, merges it into 'master' and 'development' and deletes the branch. All on local. A push to remote is required to then sync these two branches. All cooperating developers follow the same process and Pull Requests aren't involved.

It took a bit of searching to work out how to integrate gitflow and Pull Requests and it is possible. Instead of running the git finish command: commit and push the changes when done, then raise the Pull Request as you describe and follow it through. Finally, delete the branch on local manually - gitflow doesn't actually care if 'finish' is run or not. It's even possible to integrate the Pull Request / finish approaches, and desirable if one is settled on using gitflow, better described by this chap in his video - the actual description of this specific approach is close to the end:

[View:https://www.youtube.com/watch?v=ZEX67ogT658:740:466]

What's described is a way of doing what you suggest as an approach but automating a lot of it with 'standardised' functions. If that makes sense: standardised in the sense that people seem to have settled on the gitflow implementation that can be downloaded.

This has been an interesting few posts to follow and understand Jan, thanks for creating them.

RE: Firmware Version Control with GitHub part 1: Branch Strategy for New Features

Andrew J — Tue, 11 Aug 2020 17:29:10 GMT

Hi Jan,

I'm not that familiar with git although I have used it. Rather than the command line I'm using GitKraken and what you are blogging here seems to match to gitflow which is directly integrated into GitKraken.

(This isn't a question about Gitkraken but git!)

When I activate that integration it ensures that I have two branches to start from: master and development on local. This is where it would appear to differ from your manual approach - development is not a clone of master. In trying this workflow out, I created a hot fix - which created a branch, hotfix, from master - and when I committed and 'finished', it merged hotfix into master and development, and deleted the hotfix branch, all on local repository. Pushing to remote I can see the commit and the version tag created (but not the development branch.) Reading up about gitflow, it seems to me that development branch should be a clone of master as all 'dev' work, apart from hot fixes, is originated from that branch. Does that seem right to you? If so, is there a way of getting development branch to match master - rebase master on development - or is that not necessary? I would expect to push changes on development to remote but perhaps development always stays on local and never goes to remote.

Hopefully, I've asked this the right way, I'm still getting my head around the terminology and right way of working!!

RE: Firmware Version Control with GitHub part 1: Branch Strategy for New Features

Workshopshed — Sat, 09 May 2020 12:55:19 GMT

Interesting to see embedded development using these techniques. I saw a talk from Arm the other week about CI and automated testing which is something you can do once you start using tools like git.

RE: Firmware Version Control with GitHub part 1: Branch Strategy for New Features

Jan Cumps — Sat, 09 May 2020 08:19:46 GMT

What I haven't discussed here is that GitHub also has "SCRUM board" style project support:

[View:/resized-image/__size/620x161/__key/commentfiles/f7d226abd59f475c9d224a79e3f0ec07-d701b936-8d2f-4f52-a5c8-1d45d60ace0b/1104.contentimage_5F00_207784.png:620:161]

The task here is attached both to an "issue" that supports this work ....

[View:/resized-image/__size/620x499/__key/commentfiles/f7d226abd59f475c9d224a79e3f0ec07-d701b936-8d2f-4f52-a5c8-1d45d60ace0b/0508.contentimage_5F00_207785.png:620:499]

... and the related pull request(s):

[View:/resized-image/__size/353x214/__key/commentfiles/f7d226abd59f475c9d224a79e3f0ec07-d701b936-8d2f-4f52-a5c8-1d45d60ace0b/3731.contentimage_5F00_207786.png:353:214]

You can either manually move the tasks through the phases by dragging it from one lane to the other,

or enable automation where a pull request can close the issue, and then the issue completes the task.

RE: Firmware Version Control with GitHub part 1: Branch Strategy for New Features

Jan Cumps — Fri, 08 May 2020 11:40:08 GMT

For a full-fledged approach: https://nvie.com/posts/a-successful-git-branching-model/