Lesson 9 · PORTWARE Git Studio

The product's software studio: versions, changelog, comparison, baselines and review.

Goal of this lessonTo run a software product from one screen: versions, changes, review, configuration and security.

The GitHub button on the product form opens the product's Git Studio; going to GitHub is an option there. A product can have several repositories: firmware, application, library, hardware design. Each shows with its role.

Step by step

  1. Open the studio

    Click the product's Git Studio button or its card on the Git Studio › Products board. The overview shows the software version, the current baseline, the configuration items and the work under review.

    The product's Git Studio12345
    1. Sync Now: reads the repositories now.
    2. Compare Versions: what changed between two versions.
    3. New Baseline: a new software baseline of the product.
    4. Open on GitHub: going to GitHub is an option.
    5. Tabs: versions, changes, reviews, configuration, pipelines, security, requirements.

  2. Read a change line by line

    Click a commit on the Changes tab: files fold, added lines are green, removed ones red. The commit type (feat, fix, docs) is read from the message.

    A commit's diff123
    1. The commit type.
    2. Lines added and removed.
    3. File header: status, name and lines; a click folds it.

  3. Write the changelog

    Changelog in the Workbench: commits are grouped by type, the pull requests and requirements in the range are listed and the Semantic Versioning level is suggested. The result can be written to a release's changelog, or the next version created on GitHub. File-by-file comparison is in Lesson 10.

    Comparing versions123
    1. From and to version.
    2. Commit count and suggested version.
    3. Changelog: commits grouped by type.

  4. Release a software baseline

    New Baseline adds the product's repositories at their latest version. Enter the hardware revision and press Release Baseline: every line freezes to its exact commit and the requirements are recorded as they stand that day.

    A software baseline1234
    1. State: Draft → Released → Obsolete.
    2. The hardware revision it is valid for.
    3. Configuration items: each repository pinned to a version and a commit.
    4. Compare with Previous: the change report between two product versions.
Why configuration management
Which software runs on a device in the field, and which requirements it meets, is the first question in a warranty case, a recall or an audit. A baseline keeps the answer in one record (EIA-649, ISO 10007).
Writes go to GitHub
New Version, Comment on GitHub and Open as GitHub Issue create records on GitHub itself; these buttons show only to the GitHub manager role and the token needs the matching write permission. Reading changes nothing on GitHub.

Check yourself

Where does the product's GitHub button lead?
To the product's Git Studio; opening GitHub is a button there.
What changes when a baseline is released?
Lines freeze to exact commits and requirements are recorded; only a new baseline changes it.
Which level does a range with 'feat' and 'fix' commits suggest?
Minor: a feature, no breaking change.