There are many ways to manage software releases with Git. Git does not require any particular method to denote a release, though the most common method is a Git tag, and this is recommended. Further, Git Dev Platforms often provide a platform specific release feature as well. Git does not require any particular versioning scheme, but Semantic Versioning is a popular choice and recommended. The contents of release notes is also subjective, although at a minimum a Git diff between previous release tag and new release tag is recommended.
...
...
@@ -31,7 +32,7 @@ There are many strategies for versioning, with simplest ones being a single inte
A slightly more complicated one such as [Calendar Versioning](https://calver.org/) includes a date and often a single number representing the revision on that date. It turns out that many automated build tools attempt to resolve dependency compatibility automatically and this requires a standard agreed upon [Semantic Versioning](https://semver.org) scheme. In a semantic scheme API compatibility hints are provided, but assumes all libraries follow the same scheme consistently and correctly.
# The Default Branch
There are many strategies on how to treat the default branch, often called `main` (and formerly `master`), and on how / when / if to create additional branches. The simplest strategy is to only use the default branch. This is a good starting point. Often branches are useful in two specific scenarios:
There are many strategies on how to treat the default branch, often called `main` (and formerly `master`), and on how / when / if to create additional branches. The simplest strategy is to only use the default branch. This is a good starting point. Often additional branches are useful in two specific scenarios:
