Git for PC

Git for PC is the version control system Git packaged for the desktop, with the pieces that make it usable there. You get the git command itself and a terminal called Git Bash that brings the Unix tools the command expects. You also get a small graphical client and history viewer, and a credential manager that keeps you signed in to the hosting services without typing a token every push. The installer asks a dozen questions on the way in, and the answers to three of them decide whether the first week is smooth or a series of confusing warnings.

Nearly every graphical Git client, including the desktop client of the largest hosting service, either bundles this package or expects it to be installed. So the question is rarely whether to install Git for PC but how to configure it and how much of it to use.

This article walks through the parts and the settings that matter, and points out where the built-in tools stop and a separate client begins.

The command line and Git Bash

The centre of Git for PC is the git command, the same one every tutorial and every hosting service documents. It runs from any command prompt once the installer has added it to the path, which is the default.

The package also installs Git Bash, a terminal that behaves like a Unix shell and carries the tools that Git’s own scripts and most online instructions assume. ssh, curl, grep, sed, awk, tar, vim, nano are all present, so a command copied from a guide written on another platform generally works as typed.

Git Bash is where most people end up living, and the right-click entry Git Bash Here that the installer adds to folders is the quickest way in. It opens a shell already inside the repository. A companion entry opens the graphical client the same way.

Both entries can be declined at install time by people who find their context menu already crowded. Terminal enthusiasts who want tabs and themes around the same shell often run a console emulator that bundles this very package instead.

Git GUI and gitk

Two graphical tools come in the Git for PC box. Git GUI is a commit tool. It shows changed files, lets you stage them whole or by hunk, write a message and commit, and handles the everyday push and pull, branching and merging from menus. It looks dated because it is, but it is fast and it never hides what it is doing. gitk is the history viewer, a scrolling graph of commits with branches and tags, and a diff pane for whatever you click. For untangling what happened on a branch, it remains one of the clearer views available.

Neither replaces a modern client. There is no side-by-side diff with syntax colouring, no pull request view and no conflict editor beyond opening the file. People who want that use a graphical client with a visual merge tool on top, and it drives this same installation underneath. For a quick commit or a look at history, the bundled tools are enough and already there.

The credential manager

Every hosting service has stopped accepting account passwords over HTTPS in favour of tokens, and typing a token at every push is not a life. The credential manager included in Git for PC solves that. The first time you push to a repository it opens a browser sign-in, or a token prompt, stores the result in the system’s credential store, and reuses it silently from then on. It understands the sign-in flows of the major services and multi-factor prompts, and it can be pointed at a self-hosted server.

When it goes wrong, it goes wrong in one of two ways. A stored token that has expired or been revoked produces an authentication failure on every push until the old entry is removed from the credential store and the sign-in repeats.

And a machine with two accounts on the same service needs the credential to be stored per repository rather than per host, which is a one-line configuration change that the error messages never mention.

Line endings, the question everyone gets wrong

The Git for PC installer asks how to handle line endings, and this is the choice that generates the most confusion afterwards. Text files on this platform end lines with two characters, most other systems use one, and a repository shared across both will show every file as changed if the conversion is wrong.

The recommended option converts to the platform style on checkout and back to the single character on commit, which keeps the repository clean and local files native.

The second option commits as-is and converts nothing, which suits people working only with others on the same platform. The third converts on checkout only. Pick the first unless a project’s own settings file says otherwise, and know that the warning about line endings being replaced is the program doing what you asked, not a fault.

Projects that include a .gitattributes file override the choice per file type, and that is the proper fix for a mixed team.

Editor, terminal, other installer choices

The default commit editor is Vim, which is the single most-searched consequence of installing this package, because a first-time user lands in it during a merge and cannot leave. The installer lists alternatives, and choosing Notepad++, a code editor or nano saves a lot of people a bad afternoon. Vim can be swapped out later with one configuration command as well.

Other choices on the way through. The terminal for Git Bash can be MinTTY, which supports proper resizing and Unicode, or the system console, which is the one to pick if you need to run interactive programs that misbehave under MinTTY.

The pull behaviour defaults to merge, with rebase and fast-forward-only offered. The HTTPS library can be the bundled OpenSSL or the system’s own certificate store, and the latter is right on a corporate network with its own certificates.

Symbolic link support, a file system cache for faster status checks and the default branch name round out the list. Every one of these can be changed later with a configuration command, so a wrong answer means a quick search rather than a reinstall.

Large repositories and slow status

In Git for PC, on a repository with tens of thousands of files, the command that checks for changes can take seconds, because it walks the whole tree. The package includes a file system monitor that watches for changes in the background and answers instantly, switched on per repository with one configuration setting. Together with the untracked cache and the commit graph it brings status on a large monorepo down to well under a second.

Long paths, over the traditional limit, are supported by another setting that the error message about a filename being too long points you towards.

Where it stops

This is Git and the tools around it, not a hosting service and not a workflow. There is no pull request, no issue tracker and no review interface, because those belong to the server you push to. Diffs in the terminal are plain, and a proper visual comparison of two versions of a file wants a diff and merge tool configured as the external difftool, which the settings support. And the graphical tools are deliberately minimal.

People who want a polished interface over the same engine install one, and the engine does not care which.

Conclusion

Git for PC is the foundation under almost every version control workflow on the desktop, so it is for every programmer. It is also for the writer, the designer and the data analyst who has been told their project lives in a repository. Git Bash and the credential manager remove the two biggest sources of friction, and the bundled tools handle a quick commit or a look at history.

The installer’s questions deserve two minutes of attention, especially the editor and the line endings, and anyone who wants a comfortable graphical workflow should add a client on top. Get those right and this package disappears into the background, which is exactly what version control software should do.