gitflow VS release-please

Pull Requests (or Merge Requests) are merged only when (1) all of the automated tests pass; and (2) enough necessary reviewers have indicated approval.

Git doesn't tell you when it's necessary to have full test coverage and manual infosec review in development cycles that produce releases, and neither do Pull Requests.

https://westurner.github.io/hnlog/#comment-19552164 ctrl-f hubflow

It looks like datasift's gitflow/hubflow docs are 404'ing, but the original nvie blog post [1] has the Git branching workflow diagrams; which the wpsharks/hubflow fork [3] of datasift/gitflow fork [2] of gitflow [1]has a copy of in the README:

[1] https://github.com/nvie/gitflow

[2] https://github.com/datasift/gitflow

[3] https://github.com/wpsharks/hubflow?tab=readme-ov-file

https://learngitbranching.js.org/ is still a great resource, and it could work on mobile devices.

The math of VCS deltas and mutable and immutable content-addressed DAG nodes identified by 2^n bits describing repo/$((2*inf)) bits ;

>> "ugit – Learn Git Internals by Building Git in Python" https://www.leshenko.net/p/ugit/

SLSA.dev is a social construct atop e.g. git, which is really a low-level purpose-built tool and Perl and now Python porcelain.

jj (jujutsu) is a git-compatible VCS CLI: https://github.com/martinvonz/jj

"Ask HN: Best Git workflow for small teams" (2016)

A successful Git branching model - известная модель ветвления от Vincent Driessen.

Before embarking on the project, we needed to decide on our Git workflow. Having experienced the unnecessary indirection and bureaucracy of Gitflow, I immediately proposed and implemented a trunk-based strategy instead.

As a best practice, consider creating a dev branch where you can stage your code and collaborate with other developers on your team. Alternatively, you can follow the Trunk-based development branching strategy. For larger teams and complex deployment cycles, the Gitflow branching model might be more suitable.

just use Gitflow

Use git flow if you have multiple contributors (https://nvie.com/posts/a-successful-git-branching-model/)

I am using git-flow, a set of Git extensions that makes it easier to implement Vincent Driessen's branching model I have used for ages.

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

We've covered everything about writing well-formatted and structured code without worrying too much about it anymore. The only part we haven't explored yet is linting commit messages. Commitlint will help us here. It allows you to configure any rules you want for the commit message, but we're going to use the Conventional Commits specification, one of the most popular conventions you'll find.

Commit Management with Conventional Commits: The Conventional Commits methodology is adopted to maintain a clear and structured record of changes with the help of commitlint.

Validate if the commit titles adhere to the Conventional Commits Specification in Merge requests.

Check out https://www.conventionalcommits.org

Conventional Commits

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: