How to Install Git on Windows, Mac and Linux (and Set It Up Securely)

To install Git, start at git-scm.com/install. On Windows, run the Git for Windows installer linked there (or winget install --id Git.Git -e --source winget). On macOS, run xcode-select --install or brew install git. On Linux, use your distribution's package manager, for example apt-get install git or dnf install git.

The rest of this guide covers doing it properly: the official build for each OS, verifying the download, the installer options that affect security, credentials and keys, defensive settings Git documents but does not enable, and patching. Every command comes from Git, Git for Windows, Apple, GitHub or Microsoft documentation, linked under Sources.

Key takeaways

• Start at git-scm.com/install. It links Git for Windows, lists Homebrew, MacPorts and Apple's Command Line Tools for macOS, and lists each Linux distribution's command.
• Git for Windows publishes a SHA-256 hash for every installer on its GitHub release page. The winget package is not maintained by that project and may lag.
• Source tarballs on kernel.org have detached .sign files made over the uncompressed tarball.
• Use a credential helper backed by the OS keychain. The built in store helper writes passwords unencrypted to ~/.git-credentials.
• Set transfer.fsckObjects to true and safe.bareRepository to explicit. Never set safe.directory to * to silence an error.
• Patch Git like any exposed software. CVE-2024-32002 (critical) and CVE-2025-48384 (high) both turned recursive clones of untrusted repositories into code execution.

Which installer is official on each OS?

The Git project publishes source code, not installers for every platform. As the git-scm.com macOS page puts it, "any non-source distributions are provided by third parties, and may not be up to date with the latest source release."

At the time of writing, git-scm.com lists Git 2.56.0. Git for Windows 2.56.0(3) shipped on 22 October 2026 as a security fix release, while the git-scm.com Windows page still pointed at 2.56.0(2) when we fetched it. The Git for Windows release page is the source of truth.

How to avoid lookalike "git download" sites

Search results for "git download" include pages not run by the Git project or Git for Windows. Some bundle adware; some serve modified installers. A developer workstation holds SSH keys, cloud credentials and signing keys, which makes it a valuable target. A few rules:

1. Type the address yourself. Go to git-scm.com. Its Windows links point to github.com/git-for-windows/git/releases, as does gitforwindows.org.
2. Ignore sponsored results. Ads can sit above the real result and copy its title.
3. Do not trust file names. Anyone can name a file Git-2.56.0.3-64-bit.exe. Only a hash or signature check tells you what you have.
4. Skip download managers and repack sites. Neither project distributes through them, and this guide links no third party mirrors.
5. On macOS and Linux, prefer a package manager you already trust over a web page you found today.

How to install Git on Windows, step by step

Step 1: download Git for Windows

Open https://git-scm.com/install/windows. The page offers four builds:

• Git for Windows/x64 Setup, the standard installer for most PCs.
• Git for Windows/ARM64 Setup, for Windows on Arm devices.
• x64 Portable and ARM64 Portable, the "thumbdrive edition", self extracting archives that need no installation.

The Git Book calls this "the most official build" and notes Git for Windows is "separate from Git itself." Per its FAQ, 2.47.0 and later no longer support Windows XP, 7, 8 or Server 2003.

Step 2: verify the installer before running it

Before you double click, hash the file:

Get-FileHash C:\Users\you\Downloads\Git-2.56.0.3-64-bit.exe

Compare the output with the SHA-256 listed next to that file name on the release page. The verification section below has details.

Step 3: walk through the installer choices that matter

Most defaults are fine. The wording below comes from the installer's own source script, so it matches the screens.

The "Check daily for Git for Windows updates" component installs a scheduled update check. Turn it on for personal machines.

Step 4: confirm the install

Open a new terminal (PATH changes only reach new windows) and run:

git --version

Expect git version 2.56.0.windows.3 or newer.

Optional: install with winget instead

The git-scm.com Windows page gives this command:

winget install --id Git.Git -e --source winget

It also warns the Git.Git package "is not maintained by the Git for Windows project and might deviate from the latest official version." After a security release, check the version before assuming you are patched.

Optional: the portable edition

The portable build needs no installation, but it does not touch PATH, register an uninstaller or check for updates. Replacing it is on you.

How to install Git on macOS

Option 1: Xcode Command Line Tools

Apple ships Git in its Command Line Tools. Apple's TN2339 gives the command:

xcode-select --install

The Git Book notes that on macOS 10.9 and later, simply running git --version without the tools prompts you to install them. This route also installs the compilers Homebrew needs. The trade off is that Apple's Git follows Apple's schedule and often trails upstream. TN2339 shows which developer directory is active with:

xcode-select --print-path

Option 2: Homebrew

For the current upstream version, install Homebrew from brew.sh, then:

brew install git

Open a new Terminal and run git --version. If it still shows Apple's version, /usr/bin comes before Homebrew in your PATH.

Option 3: MacPorts

sudo port install git

What about the old macOS binary installer?

git-scm.com no longer links one. The community installer stopped at "version 2.33.0 / 2021". Any site offering a Git for Mac .dmg today is serving something stale or something else. Skip it.

How to install Git on Linux

git-scm.com says "It is easiest to install Git on Linux with your distribution's package manager." Here are the commands from its Linux page, each run as root (the # prompt) or with sudo:

The Git Book also shows git-all (sudo apt install git-all, sudo dnf install git-all), which adds GUI tools and integrations. Install plain git unless you need them; fewer packages means less to patch.

Getting a current version when your distro ships an old one

Stable distributions freeze versions and backport security fixes, so an older version number is not automatically vulnerable. You lose new features and new defensive settings. For something newer:

1. Ubuntu: the git-core PPA, run by the "Ubuntu Git Maintainers" team on Launchpad. Adding a PPA gives its signing key authority over package installs, so compare the fingerprint Launchpad lists, F911AB184317630C59970973E363C90F8F1B6217, with what your system imports.

sudo add-apt-repository ppa:git-core/ppa
sudo apt update
sudo apt install git

2. RHEL and derivatives, which git-scm.com says "typically ship older versions of git": build from a verified kernel.org tarball rather than adding an unvetted repository.

Building Git from source

The Git Book lists the build dependencies. On Debian and Ubuntu:

sudo apt-get install dh-autoreconf libcurl4-gnutls-dev libexpat1-dev \
  gettext libz-dev libssl-dev

On Fedora and RHEL family systems:

sudo dnf install dh-autoreconf curl-devel expat-devel gettext-devel \
  openssl-devel perl-devel zlib-devel

Download the tarball and .sign file from https://www.kernel.org/pub/software/scm/git/, verify as shown below, then build (the book's steps, with the current version):

tar -zxf git-2.56.0.tar.gz
cd git-2.56.0
make configure
./configure --prefix=/usr
make all doc info
sudo make install install-doc install-html install-info

The docs targets need asciidoc, xmlto and docbook2X; drop them if you skip the docs. A source build sits outside your package manager and nothing will update it. Consider --prefix=/usr/local so its files stay separate from packaged ones.

How do you verify a Git download?

A hash shows your file matches a value the publisher posted. A signature shows a specific key signed it. Both only help if the reference value comes from a source an attacker does not control.

Git for Windows: SHA-256 from the release page

Each Git for Windows release lists every asset with a "Filename" and "SHA-256" column. For 2.56.0(3):

• Git-2.56.0.3-64-bit.exe: dc6d3db061999136e139f31376c5582a9ed6f36a4ea12f15e54ad7fa2bfc0bf2
• Git-2.56.0.3-arm64.exe: 53cfe6358a1f0573c8c777c9ad71151df8f29986759c689c7b8a5cbb84cca495

Get-FileHash C:\Users\you\Downloads\Git-2.56.0.3-64-bit.exe

Microsoft documents SHA256 as the default and warns that MD5 and SHA1 "should not be used" for files that need protection from tampering. PowerShell prints upper case; the comparison is not case sensitive. A hash from the same release page protects against a swapped download from elsewhere, not against a compromised release page. The signature route below is stronger.

Source tarballs: PGP signatures on kernel.org

Each release on kernel.org has a .tar.gz, a .tar.xz and a .tar.sign. Kernel.org notes "the signature is made against the uncompressed version of the archive", so you decompress and verify in one pipe. Adapting kernel.org's command to Git 2.56.0:

xz -cd git-2.56.0.tar.xz | gpg2 --verify git-2.56.0.tar.sign -

You need the signer's public key first. Kernel.org documents a Web Key Directory lookup that "will verify the TLS certificate presented by kernel.org before importing these keys":

gpg2 --locate-keys [username]@kernel.org

When we inspected git-2.56.0.tar.sign on 23 October 2026, it was created on 28 September 2026 by RSA key fingerprint E1F0 36B1 FEE7 221F C778 ECEF B0B5 E886 96AF E6CB. However you obtain the maintainer's key, compare its full fingerprint before trusting it.

A first run may warn "This key is not certified with a trusted signature!" That is about your trust settings, not a bad signature; kernel.org shows trust on first use with gpg2 --tofu-policy good <KEYID>. The line you need is "Good signature". Kernel.org's signed sha256sums.asc files "are NOT intended to replace developer signatures."

For signed tags inside a repository, see how to verify a signed Git tag before you build.

Distribution packages, Homebrew and Apple

Package managers check repository signatures for you. Your job is to add only repositories you mean to trust, and to install Homebrew, MacPorts and Apple's tools only from their own sources.

First run security setup

A fresh Git install has no identity, no credential policy and no signing setup. Spend ten minutes here once.

Set your identity

The Git Book's first time setup chapter:

git config --global user.name "John Doe"
git config --global user.email johndoe@example.com
git config --global init.defaultBranch main

Then check what you set and where it came from:

git config --list --show-origin

The global file is ~/.gitconfig (on Windows, C:\Users\<you>\.gitconfig; Git for Windows adds C:\ProgramData\Git\config). Name and email are labels, not authentication; signing, below, is what proves authorship.

Credential helper versus storing tokens in plain text

Over HTTPS, Git asks a credential helper to remember your token. The two built in helpers are cache, which holds credentials in memory (default 900 seconds), and store, whose manual warns: "Using this helper will store your passwords unencrypted on disk, protected only by filesystem permissions." That file, ~/.git-credentials, ends up in backups, container images and support bundles.

Use a helper backed by the operating system instead. The gitcredentials page lists:

For GitHub, GitHub's docs recommend GitHub CLI or Git Credential Manager. With GitHub CLI installed:

gh auth login

Choose HTTPS, then answer Y to authenticate Git with your GitHub credentials. GitHub notes that with Git Credential Manager "you don't have to manually create and store a personal access token", and that Windows users need at least Git for Windows 2.29 for OAuth.

Stop credentials leaking through remote URLs

A remote URL can embed a password (https://user:password@host/path), which then sits in .git/config. The git-config setting transfer.credentialsInUrl accepts allow (default), warn or die:

git config --global transfer.credentialsInUrl die

It currently checks remote.<name>.url, not pushurl.

SSH keys

GitHub's docs generate an Ed25519 key (with ssh-keygen -t rsa -b 4096 as the fallback):

ssh-keygen -t ed25519 -C "your_email@example.com"

Set a passphrase and let the agent remember it. On macOS and Linux:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

On macOS, GitHub adds AddKeysToAgent yes, UseKeychain yes and IdentityFile ~/.ssh/id_ed25519 under Host github.com in ~/.ssh/config, then runs ssh-add --apple-use-keychain ~/.ssh/id_ed25519. On Windows, in an elevated PowerShell:

Get-Service -Name ssh-agent | Set-Service -StartupType Manual
Start-Service ssh-agent
ssh-add c:/Users/YOU/.ssh/id_ed25519

Strongest of all is a hardware security key, which keeps the private key on the device: ssh-keygen -t ed25519-sk -C "your_email@example.com" (or ecdsa-sk if Ed25519 is unsupported).

Commit signing

Signing proves a commit came from your key, not just from someone who typed your name. Git supports OpenPGP, X.509 and SSH via gpg.format. GitHub notes "SSH signature verification is available in Git 2.34 or later." With an SSH key:

git config --global gpg.format ssh
git config --global user.signingkey /PATH/TO/.SSH/KEY.PUB
git config --global commit.gpgsign true
git config --global tag.gpgSign true

For GPG, find your ID with gpg --list-secret-keys --keyid-format=long and set it with git config --global user.signingkey <ID>. Add the public key to your Git host so it can mark commits verified. Our guide on how to set up signed commits with GPG covers expiry and rotation.

Safe defaults worth setting

Git documents several defensive settings that are off by default. From the git-config reference:

git config --global transfer.fsckObjects true
git config --global safe.bareRepository explicit
git config --global transfer.credentialsInUrl die

The documentation says safe.bareRepository=explicit protects against "cloning a repository that contains a bare repository and running a Git command within that directory." safe.directory exists because Git refuses to read the config of a repository owned by someone else; it is "only respected in protected configuration" so a repository cannot whitelist itself, and * will "completely opt-out of this security check." The user protocol policy keeps a transport available when you type a command but not during "recursive submodule initialization."

For repository level hardening, see our secure defaults checklist for a new Git repository and applying Git patches safely.

How do you keep Git patched?

Why patching Git matters

Git parses data from repositories you do not control every time you clone or fetch. Two recent advisories from the Git project's own security advisory list show what that means in practice:

For CVE-2024-32002, code could run during the clone "before the user has a chance to review it"; the advisory's workaround was git config --global core.symlinks false. For CVE-2025-48384, it is to "Upgrade to the latest Git version, or avoid recursively cloning submodules in untrusted repositories." The project's advisory list shows the same pattern elsewhere, such as "Arbitrary file writes via bundle-uri parameter injection" (July 2025): risk concentrates in cloning, submodules and credential handling.

Git for Windows also bundles dependencies that need patching. Its 2.56.0(3) "security fix release" addresses the eMudhra intermediate CA compromise and Git LFS's CVE-2026-105803 (via Git LFS 3.8.1). Its FAQ says: "If you have a version older than 2.56.0(3), it is highly advisable to upgrade."

Update commands on each OS

Windows installer build. The Git for Windows FAQ: "Whether or not you enabled auto-updates during installation, you can manually run":

git update-git-for-windows

Windows via winget. From Microsoft's winget docs, upgrade by ID (plain winget upgrade lists pending updates):

winget upgrade --id Git.Git -e

Portable build. Download, verify and replace the folder.

macOS with Homebrew. From Homebrew's FAQ:

brew update
brew upgrade git

macOS Command Line Tools. Apple updates these on its own schedule. If you need a newer Git sooner, use Homebrew's.

Linux. Your distribution's normal updates cover Git. On distributions that backport, check their security notices for the CVE rather than comparing version numbers with upstream.

Source builds. Verify, rebuild and reinstall each release. Confirm any update with git --version.

Fleet checks

On a team, the real question is which laptops and CI runners still run an old Git. Record git --version in your inventory and rebuild runner images when Git or Git for Windows ships a security release.

How do you uninstall Git cleanly?

Windows

Remove "Git" from Settings, Apps, Installed apps; the uninstaller also removes the daily update task. For the portable build, delete its folder. Then decide about leftovers: C:\Users\<you>\.gitconfig, C:\ProgramData\Git\config, saved credentials (GitHub's docs: open Credential Manager, "Look for the GitHub entry and delete it"), and C:\Users\<you>\.ssh. Revoke public keys on your Git host before retiring a machine.

macOS

Homebrew's FAQ removes a formula entirely with:

brew uninstall --force git

For Apple's tools, TN2339 says: "If the /Library/Developer/CommandLineTools directory exists on your system, remove it to uninstall the command-line tools." That also removes the compilers other tools need, and full Xcode carries its own copy.

Linux

Use your package manager's remove command for the git package. If you added the git-core PPA, remove it too so its key no longer has authority over installs. Source builds live under the prefix you chose.

What to clean up on any OS

Delete ~/.gitconfig and ~/.config/git/config if you are done with them. If ~/.git-credentials exists, revoke every token in it on the Git host; deleting the file is not enough.

Common errors and how to fix them

"'git' is not recognized as an internal or external command"

Windows cannot find git.exe in PATH. Close every terminal and open a new one. If you chose "Use Git from Git Bash only", or use the portable build, Git is not in PATH by design; rerun the installer and pick "Git from the command line and also from 3rd-party software."

"xcrun: error: invalid active developer path"

On macOS this usually appears after a major OS upgrade or after deleting Xcode: the developer directory Git expects is gone. Reinstall the tools and check the active path:

xcode-select --install
xcode-select --print-path

To use full Xcode instead, TN2339 shows sudo xcode-select -switch /Applications/Xcode.app.

"detected dubious ownership in repository"

Git's source prints this when the repository is owned by a different user, and suggests:

git config --global --add safe.directory <path>

First ask why ownership differs: an external drive, a directory created with sudo, or a container volume mapped to another user ID are common harmless causes. Fixing ownership removes the need for an exception. Never add *.

"SSL certificate problem" behind a corporate proxy

TLS inspecting proxies re-sign traffic with an internal root CA that Git must trust. On Windows, rerun the installer and choose the Secure Channel backend (http.sslBackend set to schannel) so Git uses the Windows Certificate Store. On macOS and Linux, point http.sslCAInfo (or GIT_SSL_CAINFO) at a bundle that includes the corporate root. Git honours http_proxy and https_proxy, and http.proxy overrides them. Do not set http.sslVerify to false or export GIT_SSL_NO_VERIFY; that disables checks for every server.

"Permission denied (publickey)"

The server rejected every key offered. Check ssh-add has your key loaded, that the public key is on your Git host account, and, on Windows, that Git uses the SSH client whose agent holds the key. The Git for Windows FAQ covers this error, including that old DSA keys no longer work with modern OpenSSH.

Common mistakes

• Downloading from the first search result instead of following git-scm.com and checking the hash.
• Assuming the winget package is current after a security release.
• Choosing "None" for the credential helper, then pasting tokens into remote URLs or using credential.helper store.
• Setting safe.directory to * to make an error go away.
• Turning off http.sslVerify behind a proxy instead of trusting the corporate CA.
• Recursive clones of untrusted repositories on an old Git, the exact path both CVEs above used.
• Forgetting Apple's Git, which can still win in PATH after you install Homebrew's.
• Leaving CI runner images on an old Git.

Where Safeguard fits, honestly

Safeguard does not install Git, update it on your laptop or check your Git client version. Keeping the Git client itself patched on every developer machine and CI runner is your job, and the update commands above are how you do it.

Where Safeguard comes in is one layer up, in the repositories Git manages. Safeguard connects to your Git hosting (GitHub, GitLab, Bitbucket and Azure DevOps) to inventory repositories and the dependencies declared in them, matches those components against vulnerability databases, and uses reachability analysis to rank the findings your code actually calls. When a fixed version exists, autonomous remediation can open a fix pull request in that same Git host, so the fix arrives through the review and signing workflow you set up in this guide. Remediation ships switched off by default. Keeping tokens out of ~/.git-credentials and remote URLs is down to the credential helper and transfer.credentialsInUrl settings above.

Fix it without waiting for upstream

Installing Git correctly is the first step in a chain: the repositories you clone next pull in open source dependencies, and those dependencies carry their own vulnerabilities. Git itself you patch with the commands above. For the code those repositories ship, there is a faster path than waiting.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

FAQ

How do I install Git on Windows 11?

Go to git-scm.com/install/windows and download the Git for Windows x64 Setup (or ARM64 Setup on an Arm PC). Check its SHA-256 with Get-FileHash against the release page, run it, keep the recommended PATH option and Git Credential Manager, then open a new terminal and run git --version. You can also use winget install --id Git.Git -e --source winget, keeping in mind that package is not maintained by the Git for Windows project.

How do I install Git on a Mac?

Run xcode-select --install to get Apple's Command Line Tools, which include Git, or run brew install git for the current upstream version through Homebrew. git-scm.com no longer links a standalone macOS installer because the last one stopped at version 2.33.0 in 2021.

How do I install Git on Ubuntu?

Run sudo apt-get install git. For the newest upstream release on Ubuntu, git-scm.com lists the git-core PPA: sudo add-apt-repository ppa:git-core/ppa, then sudo apt update and sudo apt install git. Check the PPA's signing key fingerprint on Launchpad before trusting it.

How do I install Git in WSL?

WSL runs a Linux distribution, so use that distribution's command from the Linux table, for example sudo apt-get install git in Ubuntu on WSL. Git inside WSL and Git for Windows are separate installs with separate configuration files and separate update paths; keep both patched if you use both.

Is the winget Git package official?

It installs the Git for Windows installer, but git-scm.com states the Git.Git winget package is not maintained by the Git for Windows project and "might deviate from the latest official version." For security releases, confirm the version after upgrading.

How do I check which version of Git I have?

Run git --version in a new terminal. On Windows the output includes .windows.N, for example git version 2.56.0.windows.3. Compare it with the latest release on git-scm.com and the Git for Windows release page.

How do I update Git?

On Windows, run git update-git-for-windows from Git Bash, or winget upgrade --id Git.Git -e if you installed with winget. On macOS with Homebrew, run brew update and brew upgrade git. On Linux, use your distribution's normal update process. Then run git --version to confirm.

Should I use HTTPS or SSH with Git?

Both are secure when set up properly. HTTPS with Git Credential Manager or GitHub CLI is easiest and keeps tokens in your OS credential store. SSH with an Ed25519 key protected by a passphrase, or a hardware security key, avoids tokens entirely. What is not secure is HTTPS with a token pasted into the remote URL or saved by the store helper.

How do I verify that my Git download is genuine?

For Git for Windows, compare Get-FileHash output with the SHA-256 listed on the GitHub release page. For source tarballs, verify the .sign file from kernel.org with xz -cd git-2.56.0.tar.xz | gpg2 --verify git-2.56.0.tar.sign - and check that the output says "Good signature" from the expected key fingerprint.

What does "detected dubious ownership" mean, and is it safe to fix?

Git found a repository owned by a different user and refused to read its configuration, because a hostile repository config can run commands. It is safe to add that one specific path with git config --global --add safe.directory <path> once you know why the ownership differs. Avoid *, which disables the check everywhere.

See how Safeguard would help

None of these demos install Git. They show what happens one step later, once Git is cloning repositories and pulling in dependencies. If you want to try the CLI yourself, download it from https://safeguard.sh/download and read the setup guide at https://docs.safeguard.sh/docs/cli .

The first demo is a real CLI session. After install, safeguard opens the interactive terminal, you ask it to fix the lodash CVE in a repo, and it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. On a freshly set up machine, this is the same flow you would use on the first repository you clone with your new Git: find the vulnerable dependency, fix it locally, and commit it with the signing key you just configured.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with its device code, and then scans from the terminal. For developers who have just installed Git and cloned their team's repositories, it shows how to get dependency inventory and vulnerability checks running locally without sending project code anywhere else.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. If you work with an assistant while setting up repositories, this is how you let it look up findings and safe versions without handing it more access than you intend.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• git-scm.com: Install Git
• git-scm.com: Install Git on Windows
• git-scm.com: Install Git on macOS
• git-scm.com: Install Git on Linux
• git-scm.com: Build Git from source
• Pro Git: Installing Git
• Pro Git: First-Time Git Setup
• Git documentation: git-config
• Git documentation: gitcredentials
• Git documentation: git-credential-store
• Git documentation: git-credential-cache
• Git source: setup.c (dubious ownership message)
• Git security advisories
• Git advisory GHSA-8h77-4q3w-gfgv (CVE-2024-32002)
• Git advisory GHSA-vwqx-4fm8-6qc9 (CVE-2025-48384)
• Git for Windows
• Git for Windows FAQ
• Git for Windows 2.56.0(3) release
• Git for Windows installer script (install.iss)
• kernel.org: Git release tarballs
• kernel.org: Linux kernel releases PGP signatures
• Launchpad: Ubuntu Git Maintainers PPA
• Apple TN2339: Building from the Command Line with Xcode FAQ
• Homebrew FAQ
• Microsoft Learn: winget upgrade command
• Microsoft Learn: Get-FileHash
• GitHub Docs: Generating a new SSH key and adding it to the ssh-agent
• GitHub Docs: Telling Git about your signing key
• GitHub Docs: Caching your GitHub credentials in Git

Last reviewed: 23 October 2026. Git and Git for Windows ship security releases often; check git-scm.com and the Git for Windows release page for the current version.