cleanup

.github/workflows/format.yml

@@ -37,7 +37,9 @@ jobs:
     runs-on: ubuntu-latest
     name: DotNet Format
     steps:
-      - uses: actions/checkout@v4
+      -
+        name: Checkout
+        uses: actions/checkout@v4
       -
         name: Setup .NET SDK
         uses: actions/setup-dotnet@v4

.github/workflows/release.yml

@@ -8,15 +8,19 @@ jobs:
     name: Trigger ci flow
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@v4
-      - name: Get version
+      -  
+        name: Checkout
+        uses: actions/checkout@v4
+      - 
+        name: Get version
         id: get-version
         shell: pwsh
         run: |
           # Finding the version from release tag
           $VERSION="${{ github.ref }}".Replace("refs/tags/", "")
           "version=$VERSION" >> $env:GITHUB_OUTPUT        
-      - uses: peter-evans/repository-dispatch@v3
+      - 
+        uses: peter-evans/repository-dispatch@v3
         with:
           token: ${{ secrets.RELEASE_GITHUB_TOKEN }}
           repository: ${{ github.repository }}

docs/input/docs/learn/faq.md

@@ -49,13 +49,6 @@ SemVer.
 If you want to fix the version, use `NuGetVersionV2` which will stay the same
 after NuGet 3.0 comes out
 
-## How do I choose my branching strategy (GitFlow vs GitHubFlow)
-
-If you run `gitversion init` then choose `Getting started wizard` then choose
-`Unsure, tell me more`, GitVersion will run through a series of questions which
-will try and help point you towards a branching strategy and why you would use
-it.
-
 ## Merged branch names as version source
 
 When GitVersion considers previous commits to calculate a version number, it's

docs/input/docs/reference/configuration.md

@@ -8,16 +8,6 @@ RedirectFrom: docs/configuration
 GitVersion, starting from version 3.0, is mainly powered by configuration and no
 longer has branching strategies hard-coded.
 
-## Configuration tool
-
-If you run `gitversion init`, GitVersion will launch into a configuration tool,
-which can help you configure GitVersion the way you want it.
-
-Once complete, the `init` command will create a `GitVersion.yml` file in the
-working directory. It can be the root repository directory or any subdirectory
-in case you have a single repository for more than one project or are restricted
-to commit into a subdirectory.
-
 :::{.alert .alert-info}
 **Note**
 

docs/input/docs/reference/modes/manual-deployment.md

@@ -15,7 +15,7 @@ remain on the same pre-released version until it has been deployed dedicatedly.
 
 The thing about manual deployment is that there will be _multiple_ candidates
 to deploy on testing and it is a human choice to deploy. This means that
-GitVersion will build **the same semantic version** until that version is
+GitVersion will build __the same semantic version__ until that version is
 deployed. For instance:
 
 * 1.1.0-2+1