Github workflow

1

Hi all, i’m an hardware designer but recently i’m working even in software development using arduino framework. About 2 months ago i started to use Platformio in Vs code to completely abandon Arduino ide. I also recently started to use github + github desktop basically for my own use (i don’t have collaborators to my projects).
I usually create small firmwares for small projects that i can update over the time. I hold each firmware in a folder with version number; if i wanted to create a new “release” of a firmware (for bugs or new features) i used to copy the actual folder, rename it with the next version number and started to work in this new project. Result in my project folder i have something similar:
2020-08-06 12_46_56-Arduino-PROJECTS

Which can be a correct workflow to manage versions using github/github desktop in my use case (no collaborators, only for personal project storage and management)?
I read Github docs, but i’m a bit confused with tags, branchs, and releases…

2

I’m not a GitHub guru, but:

A branch is something you would create to allow you, perhaps, to bugfix version 2.1 while, at the same time, continuing to work on converting version 2.1 to version 3.0, for example.

Once 2.1 was bug fixed correctly, the changes could be merged into the working 3.0 files to fix the bug in those as well.

You don’t have to keep a branch when you are done with it. It can be deleted.

A tag is a manner of collecting all the files in the repository, together at their current state, in such a manner as to be able to be recreated/downloaded at will, in the future.

A release is just a tag, really. On GitHub it saves the repo files as at a specific commit and allows yourself, or anyone interested, to download the files at that point.

In addition, the release can also have binary files added. Some of my stuff, for example eBooks, have releases on GitHub where I add in the PDF which corresponds to the eBook sources at the point of the release.

In your workflow you could have your 1.0 files in the repo and tagged as 1.0, then branch off to a 2.0 version, do your work there, merge inot 1.0 and tag as 2.0. Etc.

Any version from 1.0 onwards can be reproduced at will when you checkout - by checking out the tag required. No need for separate folders for each version.

There’s a free Git book you can download (legally) from Git - Book which might be of use?

HTH

Cheers,
Norm.

1 Like
3

Many thanks!

In your workflow you could have your 1.0 files in the repo and tagged as 1.0, then branch off to a 2.0 version, do your work there, merge inot 1.0 and tag as 2.0. Etc.

Do you mean that when i want to upgrade my work from v1.0 to v2.0 i can create a “temporary” 2.0 branch, work on it, then merge and finally tag as v.2.0, right? At this point 2.0 branch can be even deleted or at least i can consider it no longer needed, right?
I ask to check if i understand…

4

Yes, exactly that.

Why not set up a test repo on your PC with just a couple of text files, tag it as 1.0. Then create a 2.0 branch, change the files to “version 2”. Switch back (checkout) the 1.0 branch and merge the 2.0 branch. Tag it as 2.0.

Delete the 2.0 branch.

Now checkout the 1.0 tag, check the files. Confirm it is version 1.0. Then do the same with the 2.0 files.

HTH

Cheers,
Norm.

1 Like
5

Done! Worked as i expected. Many thanks again.

1 Like