Skip to main content
Version: kirkstone_1-08-00

Git Workflow

Introduction​

The Clea OS project, as described on the Git Structure page, consists of various parts, i.e. various groups and repositories, on which different teams from SECO branch units actively cooperate. In order to keep the development and integration process of the various parts as qualitative and efficient as possible, it was essential to define the development flow that each member of the various teams must follow. The approach is breviously described in this page.

Trunk-Based Development​

Trunk-Based Development (TBD) is the Git workflow adopted for the Clea OS development and is a source control branching model where developers collaborate on code in a single branch called 'trunk'. This approach avoids long-lived feature branches, minimizing merge conflicts and ensuring a streamlined integration process. TBD supports continuous integration and delivery by encouraging frequent Merge Requests (MRs) and thus commits to the trunk, maintaining a always-deployable state.

Core Practices and Benefits​

Key practices in TBD include working extensively with Merge Requests (MRs) from the feature branches to the trunk, using short-lived feature branches for isolated changes. The simplicity of this model allows for rapid iteration and scaling, as seen in large organizations like Google and Facebook. The model reduces complexity, enhances code quality through continuous code review, and supports high-frequency releases.

Clea OS Workflow​

Everytime a new feature or a fix needs to be introduced in Clea OS, each developer creates a dedicated feature branch in the corresponding repository.

info

Most feature branches, commits and MRs may contain references to Jira ticket codes. For the Clea OS project, the Jira Development Panel integration on an internal Jira instance for activity tracking is indeed active.

Every time a feature/fix contained in one of these branches needs to be integrated inside the 'trunk', a MR is opened in GitLab for review. Every time a new MR is opened, a dedicated pipeline takes in charge of performing CI tests, in order to prevent to merge source code that can actually breaks the Clea OS build.
More details can be found in the page dedicated to the CI/CD structure of the Clea OS project.

Branch Management / Naming Convention​

The following section aims at describing the way branches are managed in the various Clea OS layers and Board Support Package (BSP) repositories as well as the naming convention adopted for the 'trunks'. Here below the main guidelines for branch naming are outlined:

  • No release or develop branches are present. The only branches that can contain the 'develop' label are the so-called feature branches. The stability for releasing the trunk branch is defined by a tag on the branch itself.
  • The workflow in which each MR integrates the changes into the trunk branch of the manifest repository, shall discourage the presence of long-lived and unmerged branches.
  • Each repository can have more than one trunk, each one corresponding to a major Kernel, Yocto, U-Boot release version. For instance for the moment, the trunk is called kirkstone for all repositories concerning Yocto layers. Once a new Yocto main version will be released and supported withing Clea OS, a new trunk will be created in the same repository.
  • For all meta-layers inside the seco group, for the seco-manifest and the seco-base repositories the trunk branch takes the name of the Yocto version (i.e. kirkstone at the moment).
  • For all repositories inside the bsp group (apart from specific cases described below), the naming convention of the trunk branches is seco_<source_version>. For example seco_lf-5.10.y is the main branch for the Linux Kernel version released for SECO NXP boards.
  • For the poky repository the trunk branch anming convention is seco/<source_version>/develop.
  • For all repositories inside infrastructure group, the tools group, the Rockchip tools group and the seco-3rd-party group no particular naming convention is followed.