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.
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
...
@@ -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.
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
# 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:
