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 Release with GitHub: Branch, Issue, Pull Request and Project support
  • 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: 9 May 2020 10:40 AM Date Created
  • Views 2067 views
  • Likes 7 likes
  • Comments 7 comments
  • tutorial
  • github
  • version_control
  • learning
  • git
  • gitlab
  • github_repository
Related
Recommended

Firmware Release with GitHub: Branch, Issue, Pull Request and Project support

Jan Cumps
Jan Cumps
9 May 2020

image

 

Scenario:

  • Developments for current cycle are finished (by the developer. That's me) and are available in my repo's development branch.
  • All that code has already been tested, built (by the developer. That's me).
  • All code has been reviewed and accepted, as part of the development cycle (by the development branch owner. That's me).
  • Release manager (hey, that's me too) now has the task to collect all development and integrate it into the release. That's the master branch.

 

Tools I'd like to use:

  • GitHub issue module to define the work item: create release
  • GitHub project module to manage the work, with "automation"
  • Git command line to merge the development code into the master code
  • GitHub pull request module to accept that merge into the master branch

 

Goal

  • a: have a process and tool support for developer and approver / reviewers
  • b: have a project view of progress for the project manager, without the developer and reviewers ever have to do project management updates.

 

 

 

Step 1: Assign the work - create an issue

 

image

An issue can be a bug report, but also a task such as creating a release.

image

By assigning it to someone (hey, that's me again), and linking it to a project, you automatically get scrum / Kanban style functionality.

 

image

 

Step 1a: Review the project board

 

I want to use automation as much as possible. The project integration is supposed to give insight. Not give more work to the developer.

 

image

You can see that our board has one new card, in the To do lane. Let's just look, don't touch.

 

Step 2: Start working on the release

 

I have this issue open on my name now, with the project board reflecting this.

From the issue, we can flag that we're going to work on it:

image

 

Step 2a: Review the project board

 

As expected, the task has moved lanes.

image

 

Step 2b: Do the work - create a release pull request to merge development into master

 

Creating a release is actual work. We can change statuses and stuff, but that'll never get things done.

We need to make the hands dirty. In Git.

 

$ mkdir release20200509
$ cd release20200509
$ git clone -b master https://github.com/jancumps/msp432.git

I specify the master branch here, although that is the default branch.

I do it because in reality I automated this in a batch script with parameters.

So I can pull in changes from branch B into branch A by just defining the two branch names (+ the name of the feature branch I temporary create to support the pull request).

 

 

$ cd msp432
$ git merge development -m "sync development changes into the master branch"

 

image

 

$ git checkout -b release20200509
$ git push --set-upstream origin release20200509

 

image

Our release branch is now ready to be integrated into master:

 

image

Review the pull request content before creating it. You get an overview of all the files that changed, and what has changed.

 

image

 

Also check that you are actually pulling the correct branch into the correct branch.

In this case, the goal is to pull the changes from development (collected in temporary branch release20200509) into master.

image

 

Link the pull request to the project card. See next section - you only have to do this if you want to get a view of pull request progress on the board.

image

 

Step 2c: Review the project board

 

Because I selected the project in my pull request, a new card is created on the board.

You don't have to do this. If you just want to stick to one card to manage the issue, just don't add the pull request to your project.

But if you want to enable tracking of the approvals by the reviewers (hey, that's me) , you can use this functionality.

 

image

 

Step 2d: Flag that you've submitted the issue for review

 

image

You're finished with the work. You as developer (hey, that's me) can flag that in your issue.

 

Step 2c: Review the project board

image

 

Your issue card has progressed. Both developer and reviewer tasks are visible for the project manager (hey, all 3 me) on the board.

 

 

Step 3: Review the pull request

 

Here I can't show the full flow because I haven't set up a second contributor to review the pull request.

I'm using admin override to approve my own request.

GitHub makes this very clear by using bright red for all admin override options.

 

image

Let's set it to In Review.

image

 

Step 3a: Review the project board

 

image

 

Step 4: Approve and merge the pull request

 

image

 

In the real world an approver would be assigned. You can select one from all the repo members that have commit access to the destination branch.

In my case, I use the admin override to accept my own pull request:

image

 

The pull request card moves to done.

I always delete branches that have been accepted. Some platforms, such as Azure DevOps, allow that this happens automatically at acceptance.

 

image

 

Step 4a: Review the project board

 

image

The reviewer / approver tasks are done. The card moved to the done lane.

Now it's time for the release manager to update the issue.

 

Step 5: Release Done. close the issue

 

Totally optional, the release manager can flag that the pull request is reviewed and done.

In a work situation, I'd flag that it's been sent for review, just to keep the project manager aware.

image

The card will then show up in the relevant lane on the board.

 

What you have to do as release manager, is close the issue.

The acceptance of the pull request is automatically recorded (see purple label):

 

 

image

Enter a closure message and close the issue. You have finished the task. The release is confirmed and available in the master branch.

In a managed way. Goal a.

 

 

 

Step 5: Review the project board

 

image

 

This is what project board automation can offer:

Having a project view of the activities, based on real activities by the developers, release manager, reviewers and approvers.

If you've ever been in a situation where you have to maintain task status as a separate activity in a project management system, you may appreciate that,

if you define a repeatable process, you can have the status on the project board up to date.

Without updating project stats. Goal b.

 

The one that's responsible for the issue can manage all statuses from the issue (me image).

The one responsible for review and acceptance can manage all statuses by approving review and accepting merge (me image).

The one responsible for project management gets a real time view of everyone's duties (me too image - there's no escape in a one person repo).

 

 

Comments and critique, as always, welcome in the comments. Fire away.

 

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

  • wolfgangfriedrich
    wolfgangfriedrich over 5 years ago +3
    Thanks, Jan. This is a super helpful tutorial for advanced uses. With a diagram like this, I finally started understanding the concept of git: - W.
  • Jan Cumps
    Jan Cumps over 5 years ago in reply to shabaz +3
    If Git designers goofed up one thing, it's reusing terms that have been used since forever in the problem domain, then use them for an unrelated activity. Git commit Git checkout It makes my life as an…
  • shabaz
    shabaz over 5 years ago in reply to wolfgangfriedrich +2
    Nice diagram. It confused me for ages too, until I saw something like that. This is the type of diagram that software developers will want, even though it is possible to operate git without needing to…
  • shabaz
    shabaz over 5 years ago +1
    Hi Jan, Great write-up! I had not realized github had such board capability for free! That's a massive boost for software projects for hobbyists too.
  • DAB
    DAB over 5 years ago +1
    Nice tutorial Jan. DAB
  • Jan Cumps
    Jan Cumps over 5 years ago +1
    i forgot to link the pull request to the issue in my writeup .
  • shabaz
    shabaz over 5 years ago in reply to Jan Cumps +1
    Agree with that! : )
  • shabaz
    shabaz over 5 years ago in reply to Jan Cumps

    Agree with that! : )

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

    i forgot to link the pull request to the issue in my writeup image.

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

    Nice tutorial Jan.

     

    DAB

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

    If Git designers goofed up one thing, it's reusing terms that have been used since forever in the problem domain, then use them for an unrelated activity.

    Git commit

    Git checkout

     

    It makes my life as an advocate unneccesarily difficult.

    • Cancel
    • Vote Up +3 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • shabaz
    shabaz over 5 years ago

    Hi Jan,

    Great write-up! I had not realized github had such board capability for free! That's a massive boost for software projects for hobbyists too.

    • Cancel
    • Vote Up +1 Vote Down
    • Sign in to reply
    • More
    • Cancel
>
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