Brew install git: replace the copy Xcode handed you

Running brew install git on a Mac takes about a minute and appears to do nothing. A git command already worked before, it still works afterwards, and the version it reports may not have moved at all. Nothing failed. Two different copies of git now exist on the machine and the shell is still reaching the old one, because installing software and changing which software answers to a name are separate operations on macOS.

Sorting that out is worth more than the install itself. What follows is what the shipped copy actually is, what the formula puts on disk, and the one line that decides which of them runs.

The git at /usr/bin is not a copy of git

This is the fact that explains everything else, and it is documented in a manual page that nobody opens: the one for xcode-select.

That page lists, under FILES, a long set of paths in /usr/bin that are not programs but shims. The entry covering them says they run the matching BSD tool from the active developer directory. /usr/bin/git is on that list, along with /usr/bin/git-receive-pack, /usr/bin/git-shell, /usr/bin/git-upload-archive and /usr/bin/git-upload-pack.

So the file at /usr/bin/git is a redirector. The real binary lives inside whichever developer directory is currently selected, for example /Applications/Xcode.app/Contents/Developer, and xcode-select --print-path reports which one that is. xcode-select --switch changes it for every user on the machine and needs superuser permissions, while the DEVELOPER_DIR environment variable overrides it for one shell session without them.

Three consequences follow, and each one accounts for a common confusion.

The version of git reported by /usr/bin/git moves when Xcode moves. Updating Xcode can change it. Switching to a beta Xcode can change it again, and switching back changes it a third time. Nothing about git was updated in any of those steps.

If the Command Line Tools are not installed at all, invoking the shim triggers the installation dialog rather than running anything. That is xcode-select --install by another route, which is also what git's own installation page names as the Xcode route.

And the copy that arrives this way is bound to the Xcode release cycle rather than to git's. The official installation page for macOS is blunt about the category it falls into:

Note that any non-source distributions are provided by third parties, and may not be up to date with the latest source release.

What the formula actually installs

The git formula currently carries version 2.55.0. The latest source release published by the project is also 2.55.0, with release notes dated 29 June 2026, so the packaged version and upstream are the same release.

It arrives as a bottle, which is a prebuilt binary, wherever one exists. Bottles are provided for macOS on Apple Silicon across Golden Gate, Tahoe, Sequoia and Sonoma, for macOS on Intel at Sonoma only, and for Linux on ARM64 and x86_64. On an Intel Mac past Sonoma there is no bottle, which means a build from source and therefore Xcode or the Command Line Tools.

The formula depends on pcre2 at 10.48 and gettext at 1.0, and adds pkgconf at 3.0.7 when building from source. It uses curl and expat from macOS rather than installing its own. Licensing is a combination: GPL-2.0-only and GPL-2.0-or-later and LGPL-2.1-or-later and BSD-3-Clause and MIT.

What lands on the path is seven binaries: git, git-cvsserver, git-receive-pack, git-shell, git-upload-archive, git-upload-pack and scalar. Two absences surprise people who have used a Linux distribution's package:

The Tcl and Tk interfaces, meaning gitk and git-gui, are in a separate git-gui formula. Git's own installation page gives the command for them, which is brew install git-gui. Subversion interoperability, meaning git-svn, is in a separate git-svn formula. Installing the main formula and then finding gitk missing is not a broken install.

The formula's own usage numbers give a sense of scale: 37,186 installs in the last 30 days, 260,670 in 90 days and 1,434,005 in a year. Of the 30 day figure, 36,192 were installs on request rather than as someone else's dependency, so this is overwhelmingly a package people ask for by name. The same page records 3,900 build errors, which is the count of source builds that failed, and a reminder that the bottle path is the smooth one.

Where it lands, and why PATH decides everything

Homebrew does not install files outside its prefix. Each package goes into its own keg inside the Cellar, and the files are symlinked out into the prefix. The prefix is /opt/homebrew on Apple Silicon, /usr/local on an Intel Mac, and /home/linuxbrew/.linuxbrew on Linux.

So after the install there are two git executables reachable by name: the shim at /usr/bin/git and the symlink at /opt/homebrew/bin/git. Which one runs is decided entirely by which directory appears first in PATH.

That ordering is not set by the install. It is set by a line in the shell configuration file, and the documentation is explicit that skipping it leaves Homebrew not working:

eval "$(/opt/homebrew/bin/brew shellenv)"

That goes in ~/.zshrc for zsh or ~/.bashrc for bash, with the prefix path matching the machine. Until it is there and the shell has been restarted, git continues to mean the shim, and every install performed in the meantime sits on disk unused.

The check afterwards is which -a git, which prints every match in PATH order rather than stopping at the first. Two lines with the Homebrew path on top means the new copy wins. Two lines with /usr/bin/git on top means the configuration line is missing, in the wrong file, or being overridden by something later in the startup sequence.

The requirements that turn an install into an afternoon

Homebrew's own requirements page has moved further than most guides assume, and three items on it decide whether brew install git is a one minute job.

The supported CPU is Apple Silicon. Using a 64-bit Intel CPU is documented as a Tier 3 configuration, and that applies to every Intel Mac that can run Homebrew at all, including those using OpenCore Legacy Patcher. The supported operating system is macOS Sequoia, meaning 15, or higher. On Apple Silicon, macOS 15 through 27 is described as best and supported, while macOS 11 Big Sur through 14 Sonoma are unsupported but may work. macOS 10.15 Catalina and older will not run Homebrew at all.

Developer tools are conditional rather than universal. Xcode or the Command Line Tools are required to build formulae from source. On Apple Silicon, casks and bottles install without developer tools at all. On Intel macOS, developer tools are required even for bottle installation. Combined with the bottle list above, an Intel Mac is the configuration where git via Homebrew most often turns into a compile.

Two smaller items catch scripts rather than people. The one-line installer uses the Bourne-again shell at /bin/bash, and zsh, fish, tcsh and csh will not run it. And for automation, prefixing NONINTERACTIVE=1 gives a run that does not prompt for passwords. There is also a .pkg installer for macOS, for interactive or unattended MDM installation, which supports Apple Silicon only and installs to the same default prefix.

Worth knowing for anyone who avoided Homebrew over permissions: the installer places the prefix so that sudo is not needed after the initial installation when installing formulae. Some casks and system services still require elevated privileges, and HOMEBREW_NO_SUDO=1 disables the calls explicitly.

The three routes compared

Git's installation page for macOS lists three options, having retired a fourth. The binary installer maintained by Tim Harper stopped at version 2.33.0 in 2021 and is no longer linked, with no plans to resume.

	Xcode Command Line Tools	Homebrew	MacPorts
Command	xcode-select --install	brew install git	sudo port install git
Version delivered	tied to the installed Xcode	2.55.0, matching the current source release	set by the port tree
Where it lands	inside the active developer directory, reached through a shim in /usr/bin	a keg in the Cellar, symlinked into the prefix	its own prefix
Needs sudo to install the package	no, but xcode-select --switch does	no, after the initial setup	yes
gitk and git-gui	not part of it	a separate formula	separate ports

One more difference sits under the table and matters more than the rows in it. The Xcode route delivers git as part of a toolchain, so its version is a side effect of a decision made about Xcode. The Homebrew route delivers git as a package with its own version number, its own dependency list and its own upgrade command, which is why it can be pinned, rolled back or upgraded on its own schedule. For a machine where git is incidental, the first is less to think about. For a machine where a specific git behaviour is being relied on, the second is the only one that can be stated as a fact rather than inferred from what Xcode happens to contain.

The honest summary is that all three work and the difference is who controls the update. The Xcode route updates when Apple ships a new Xcode. The Homebrew route updates when brew upgrade runs. Neither is wrong, and the failure mode is having both and not knowing which one is answering.

The check that takes ten seconds

Three commands settle the state of the machine, and running them once after any Xcode update prevents the confusion from coming back.

which -a git lists every git in PATH, in the order the shell will try them. git --version reports what the winner is. xcode-select --print-path reports which developer directory the shim points at, which explains the version if the shim is the winner.

There is a fourth check worth running once rather than routinely. Because /usr/bin holds shims for git-receive-pack, git-shell, git-upload-archive and git-upload-pack as well, a repository served over SSH from the machine can end up using the shipped helpers while interactive work uses the Homebrew binary. That mismatch is harmless most of the time and confusing exactly once, when a push behaves differently from a local operation. Knowing the two sets exist is enough to recognise it.

Doing that means having a terminal open next to the files being worked on, which is exactly the loop that gets tedious when the folder is in one window and the shell is in another. A file manager with a built-in terminal gives each folder its own shell, so the command runs in the directory already on screen without a cd. The Features page describes how the folder view and the shell stay pointed at the same place, and Compared with other file managers sets out plainly what such a tool leaves to an editor.

What to change first

Run which -a git before anything else, because if /usr/bin/git is still on top then the install that appeared to succeed is not in use. Add the brew shellenv line to the shell configuration file, restart the shell, and check again. If jumping between a folder window and a terminal is the part that wastes the time, Atriens keeps them in one place.