Development Workflow
Last updated
Last updated
Adopting best practices for Git Branching, Versioning, Conventional Commits, and Release process. Simplify Developer Workflow and provide a great Developer Experience (DX)
Our ultimate goal:
Business value
Monorepo (apps & libs)
Fully automated release
Enforce Semantic Versioning specification
Use formalized commit message convention to document changes in the codebase
Publish on different distribution channels i.e, SNAPSHOT on develop, hotfix branches and Stable in main branch
Avoid potential errors associated with manual releases
Here, we’ve standardised on:
Scaled GitHub Flow as git branching strategy
Semantic-Release for release process
Semantic Versioning 2.0.0 for versioning
Conventional Commits for commit messages
Git installed via brew brew install git
And which git should output /opt/homebrew/bin/git.
Copy .gitconfig file as described in Dotfiles to your home directory. i.e., ~/.gitconfig
Next, we'll define your Git user (should be the same name and email you use for GitHub):
Also copy .gitattributes and .gitignore files as described in Dotfiles to your home's my directory. i.e., ~/my
Customize your .gitignore visiting gitignore.io and fill it what you need.
Cocogitto is a CLI for Conventional Commits , Semantic Versioning and Release.
We will be using branching strategy that is based on GitHub Fow, but with a greater emphasis on safety when making changes to the main branch and the ability to scale to large projects and teams.
A single main branch is always production-ready – the tests are green, and all changes are verified. The main branch is protected, meaning direct commits are not allowed.
Changes to the code are made in a separate feature branch. Always create your feature branches from main.
To merge changes from a feature branch into main, you create a merge request that must pass through quality gates. Quality gates, which can be customized to fit your team’s workflow, are sets of conditions that have to be met in order to merge:
Approval in a turn-based code review. A reviewer comments on the code and passes the turn to the author to make revisions until the changes are finally approved by the reviewer.
A successfully completed GitHub Action check job.
An external check, which passes if an external CI/CD service like Codecov reports that the build is successful.
Safe Merge is an additional safety step before finally merging changes from a feature branch into main. GitHub Actions workflow perform quality checks with an Automation build and e2e testing in isolated env. If the checks are successful, the changes from feature are finally merged into main.
If your project involves public releases, you should use release branches created from main. If necessary, last-minute changes are cherry-picked from main to a particular release branch.
Following this flow allows you to configure quality gates to achieve higher-quality code and a stable, protected main branch, with:
Safe Merge for feature branches.
Code owners for mandatory reviews in critical code areas.
GitHub Actions build status as quality gate criteria for merge requests.
Cocogitto is a CLI and GitOps toolbox for the Conventional Commits and Semver specifications.
Check the docs for all sub commands and features.
Initialize an existing repo with cog init which generate cog.toml file in project's root. Customize as per Instructions
You can copy language specific GoLang, Java, Node or Generic cog.toml file to your repository and customize it.
Note: rename above file to
cog.toml
To protect your commit history, and your git remote, cog have builtins git hooks
We recommend installing at lease commit-msg hook for each of your repositories.
To create conventional commits you can use the cog commit command. Examples:
Running cog log displays additional conventional commit information.
Running cog check will check your commit history against the conventional commit specification
Once you have spotted invalid commits you can quickly fix your commit history by running cog edit.
DANGER: Using
cog editwill modify your commit history and change the commit SHA of edited commit and their child.
Alternatively, you can use git commit --amend to fix commit messages:
If you want to rewrite multiple
non-conventional commitmessages, follow: How to change a Git commit message after a push
cog changelog can generate changelog automatically.
You can specify a custom changelog range or tag like so :
cog bump will calculate the next version based on your commit history since the latest semver tag.
The bump subcommand will execute the following steps :
Calculate the next version based on the commit types since the latest tag.
Append the changes for this version to CHANGELOG.md.
Execute a set configuration defined pre-bump hooks.
Create a version commit containing changes made during the previous steps.
Create a git tag on the version commit.
Execute a set of configuration defined post-bump hook.
This following command bump VERSION number and push changes and tag to remote
Check the GitHub Actions for Cocogitto Here
