gitflow VS release-please

For us it was git-flow (https://github.com/nvie/gitflow). A straightforward yet effective way to impress momentum in the use of basic strategies: master branch is for production, feature/... for developing new stuff, devel(op) branch for preparing next release (merging feature and hotfixes), release/... for release candidates, hotfix/... for zero-day or fixes on production... Absolutely nothing new, absolutely easy to do.

As a beginner - each of stash, branch, staged and remote is just a swimlane, kinda like illustration here: https://nvie.com/posts/a-successful-git-branching-model/ but can't remember where did I read it initially

Another thing that other suggested me in the comments is to use trunk-based development, which from what I understand is to only create branches directly from master, for anything you do: bugfix, hotfix, feature. Keep them short-lived, then merge back to master. It also sounds like a good idea for me (I've been getting so many options in this short time and overwhelming). Do you think trunk based development is also a good idea? It soudns similar to what GitHub suggests (GitHub Flow: https://docs.github.com/en/get-started/quickstart/github-flow), and even the guy I first got the idea of the drawing above, suggested to use something like GitFlow: https://nvie.com/posts/a-successful-git-branching-model/

Please, also consider that the GitFlow's owner himself nowadays discourages teams from using GitFlow, as he commented in his web page https://nvie.com/posts/a-successful-git-branching-model/

if you can perform all steps described in this doc (which is similar to what most companies do), you are good: https://nvie.com/posts/a-successful-git-branching-model/

There is git flow approach in place, which usually means multiple feature *branches exist at the same time in a remote repository. There is at least one *pull request per story. Each pull request needs to go through an integration* process* meaning the newest commit in a pull request triggers a fresh CI build. That’s being done in order to ensure the newest change won’t introduce any flaws. Yep, automation and unit test suites test each software incrementation. Software Engineers in Test (SET) writes automation tests as “a part of“ the feature in some cases.

This is more easier version of that: https://nvie.com/posts/a-successful-git-branching-model/

Under Linux I use gitflow and gitversion. The former helps me with branch and tags management, the latter keep tracks of the semantic version in a semi-automatic fashion (given a branch/commit/tag it generate a semver automatically based on the repo log). Gitflow should be supported by GUI tools too, but I'm more a CLI guy.

Manage change in automation: Changes to your infrastructure should be made using automation and IaC Tool, such as CDK or terraform. The changes that need to be managed include changes to the automation, which then can be tracked and reviewed, for example, in a VCS such as git and services such as GitHub with a branching model, such as git-flow.

Conventional Commits is a method of writing commit messages that is also machine-readable. The goal is to make it easier to automate the release process, generate changelogs, etc.

I think Release Please (https://github.com/googleapis/release-please) could augment this solution a bit... It can increment version numbers per module in your monorepo and write them into a changelog. It uses conventional commit messages (https://www.conventionalcommits.org/en/v1.0.0/) to decide whats a major / minor / patch change.

Personally I tend to use goreleaser together with release-please and conventional commits. This gives me an automated PR which is updated when the main branch changes. It includes a version bump and changelog update based on the changes since the last release. To cut a new release, I simply merge the PR.

Commits in the git should follow the style https://www.conventionalcommits.org

We are using dlx since our changelog was generated by the rules of Conventional Commits. If you don't need it, do this:

https://www.npmjs.com/package/standard-version (showing as deprecated and recommends below link) https://github.com/googleapis/release-please

Yes, our team loves conventional commits, but found that they do not communicate risk

(Generally speaking my commit messages are at least partially inspired by https://www.conventionalcommits.org/.)

Because I'm really convinced that atomic commits are one of the key to projects quality and automation (see Conventional Commit and Semantic Release for example), I do my best to correct these commits using Git rebase.

To that end, I've had good success with `replease-please`: https://github.com/googleapis/release-please . It's available as a GitHub Action and works out of the box very easily. It does tagging, publishing, editing the CHANGELOG, creating a release and more. Whatever you want it to, really, using a bool flag in the CI pipeline that triggers after a release-please release was made aka merged into main.