使用 Homebrew, chocolatey, scoop, winget 安装 gitversion

项目链接

• 主页
• 仓库
• 上游文档
• 软件包管理器页面

命令和别名

• gitversion

项目历史

The GitTools/GitVersion repository dates to 2013 and grew around a narrow problem in Git-based release automation: projects wanted SemVer numbers without hand-editing version files on every build. Its official README describes the core idea as looking at Git history and working out the Semantic Version of the commit being built.

The project evolved from a .NET-oriented CLI into a family of build integrations. The official README lists GitHub releases, Chocolatey, NuGet packages for the .NET tool and MSBuild task, Homebrew, Winget, Azure Pipelines, GitHub Actions, and Docker artifacts, reflecting a tool meant to sit inside many build systems rather than one local shell.

采用历史

GitVersion became significant in the .NET and CI ecosystem because it encoded common GitFlow and trunk-style versioning rules into a repeatable build step. Its documentation emphasizes use in command-line and continuous-integration contexts, where build servers need the same version calculation as developer machines.

Package-manager metadata in this batch shows GitVersion distributed through Homebrew, Chocolatey, Scoop, and Winget. Combined with the official NuGet, Azure Pipelines, GitHub Actions, and Docker artifacts, that spread shows adoption across local developer tooling and hosted build infrastructure.

使用方式

Practitioners use GitVersion to generate version variables during builds, then feed those values into package metadata, assembly attributes, container tags, release names, or CI outputs. The common workflow is to run the CLI or an integration from a checked-out Git repository and let GitVersion infer the SemVer value from repository state.

Teams also add GitVersion.yml or GitVersion.yaml files when the default branching and incrementing rules need to match their release process. That configuration keeps version policy near source code while avoiding custom scripts for every pipeline.

为什么软件包爱好者会关心

GitVersion matters to package maintainers because it makes version numbers reproducible from source history. That is attractive for automated package builds, where the package version should be explainable from tags and commits rather than a mutable build-server counter.

It is also a good example of a CLI that became a packaging surface in its own right: the same versioning engine is exposed as a standalone executable, a .NET tool, an MSBuild task, CI marketplace integrations, and container images.

时间线

• 2013: The GitTools/GitVersion repository is created on GitHub.
• 2015: GitVersion 3.3.0 appears in the GitHub releases feed.
• 2020: GitVersion 5.x tags show the tool's continued shift toward broad build-system integration.
• 2026: Repository activity and packaged artifacts show ongoing maintenance.

Related projects

• Semantic Versioning supplies the version-numbering convention GitVersion calculates.
• GitFlow-style branch models influenced many of GitVersion's documented branch and incrementing rules.
• GitHub Actions, Azure Pipelines, MSBuild, NuGet, Docker, Homebrew, Chocolatey, Scoop, and Winget are distribution or integration surfaces named by the project and package metadata.

来源

• https://api.github.com/repos/GitTools/GitVersion
• https://github.com/GitTools/GitVersion
• https://gitversion.net/docs
• https://gitversion.net/docs/learn/why
• https://gitversion.net/docs/usage