In a previous post we saw how to use GitVersion to generate version numbers following Semantinc Versioning (using GitFlow as a branching strategy). Today we will do the same exercise but using GitHubFlow as a branching strategy. Let's start creating a new Git repository:
mkdir gitversion-githubflow
cd .\gitversion-githubflow\
git init
Run the command dotnet-gitversion init
to start the GitVersion setup:
GitVersion init will guide you through setting GitVersion up to work for you
Which would you like to change?
0) Save changes and exit
1) Exit without saving
2) Run getting started wizard
3) Set next version number
4) Branch specific configuration
5) Branch Increment mode (per commit/after tag) (Current: )
6) Assembly versioning scheme (Current: )
7) Setup build scripts
Select option 2:
The way you will use GitVersion will change a lot based on your branching strategy. What branching strategy will you be using:
1) GitFlow (or similar)
2) GitHubFlow
3) Unsure, tell me more
Select again option 2:
By default GitVersion will only increment the version when tagged
What do you want the default increment mode to be (can be overriden per branch):
1) Follow SemVer and only increment when a release has been tagged (continuous delivery mode)
2) Increment based on branch config every commit (continuous deployment mode)
3) Each merged branch against main will increment the version (mainline mode)
4) Skip
And finally, option 2. As the last step, the wizard will show us to the first menu, select option 0 (Save changes and exit
). Run dotnet-gitversion /showconfig
to see the current GitVersion configuration. GitVersion added a file called GitVersion.yml; we will use this file as our first commit:
git add .
git commit -m 'initial commit'
Then run the dotnet-gitversion
command:
{
"Major": 0,
"Minor": 1,
"Patch": 0,
"PreReleaseTag": "ci.0",
"PreReleaseTagWithDash": "-ci.0",
"PreReleaseLabel": "ci",
"PreReleaseLabelWithDash": "-ci",
"PreReleaseNumber": 0,
"WeightedPreReleaseNumber": 55000,
"BuildMetaData": null,
"BuildMetaDataPadded": "",
"FullBuildMetaData": "Branch.master.Sha.ac95b6b7ced4ad04b43ba4d90a5714be322badd7",
"MajorMinorPatch": "0.1.0",
"SemVer": "0.1.0-ci.0",
"LegacySemVer": "0.1.0-ci0",
"LegacySemVerPadded": "0.1.0-ci0000",
"AssemblySemVer": "0.1.0.0",
"AssemblySemFileVer": "0.1.0.0",
"FullSemVer": "0.1.0-ci.0",
"InformationalVersion": "0.1.0-ci.0+Branch.master.Sha.ac95b6b7ced4ad04b43ba4d90a5714be322badd7",
"BranchName": "master",
"EscapedBranchName": "master",
"Sha": "ac95b6b7ced4ad04b43ba4d90a5714be322badd7",
"ShortSha": "ac95b6b",
"NuGetVersionV2": "0.1.0-ci0000",
"NuGetVersion": "0.1.0-ci0000",
"NuGetPreReleaseTagV2": "ci0000",
"NuGetPreReleaseTag": "ci0000",
"VersionSourceSha": "ac95b6b7ced4ad04b43ba4d90a5714be322badd7",
"CommitsSinceVersionSource": 0,
"CommitsSinceVersionSourcePadded": "0000",
"UncommittedChanges": 0,
"CommitDate": "2022-07-02"
}
As we can see, the current FullSemVer
is 0.1.0-ci.0
. Let's create our first feature branch:
git checkout -b feature/MyFeatureA
Run the command dotnet-gitversion /showvariable FullSemVer
:
0.1.0-MyFeatureA.0
Add a commit to see how this version number starts to change:
git commit -m 'featurea A: first change' --allow-empty
Run the command dotnet-gitversion /showvariable FullSemVer
again:
0.1.0-MyFeatureA.1
Let's merge the feature branch to the master
branch:
git checkout master
git merge --no-ff feature/myFeatureA
git branch -d feature/myFeatureA
Run dotnet-gitversion /showvariable FullSemVer
:
0.1.0-ci.2
We will repeat the last steps a couple of times to see how FullSemVer
changes. Here is the result as seen through the git log --oneline --graph
command:
* eb76de2 (HEAD -> master) Merge branch 'feature/myFeatureC' into master
|\
| * a38b9b5 featurea C: first change
|/
* d2928f3 Merge branch 'feature/myFeatureB' into master
|\
| * 6f736a8 featurea B: first change
|/
* 2f06433 Merge branch 'feature/myFeatureA' into master
|\
| * 081792b featurea A: first change
|/
* 59ac5ad initial commit
Run dotnet-gitversion /showvariable FullSemVer
to see the new value:
0.1.0-ci.6
Great, the version number is moving together with our number of commits. But what else can we do?. Let's tag our master
branch to see what happens:
git tag '1.0.0'
Run dotnet-gitversion /showvariable FullSemVer
:
1.0.0
As we can see, the value follows what we tag. Now, we will create a hotfix branch, a new commit, and merge it back to master
:
git checkout -b hotfix/myHotfixA
git commit -m 'hotfix A: first change' --allow-empty
git checkout master
git merge --no-ff hotfix/myHotfixA
git branch -d hotfix/myHotfixA
Run dotnet-gitversion /showvariable FullSemVer
:
1.0.1-ci.2
To see more examples using GitHuibFlow, you can check the official documentation here.