Getting Started with Git and GitHub

A version control system (VCS) records the history of a set of files as a sequence of snapshots, so that any earlier state can be recovered, two states can be compared, and changes made independently by different people can be combined. Git is a distributed version control system (DVCS): unlike older centralized systems, which keep the full history only on one server and give each developer just the files for a single checkout, Git gives every clone the entire history of the project. There is no technical difference between the copy on a developer’s laptop and the copy on a server — both are complete repositories that can exchange history with each other.

That has practical consequences worth internalising before running a single command:

Git is the command-line tool (and the underlying data model) that implements this. It has no concept of user accounts, issues, pull requests or a web page — it only manages repositories and the history inside them. GitHub is a separate product: a hosting service that stores Git repositories on its servers and layers collaboration features on top — a web UI, access control, issues, pull requests, code review, Actions for CI/CD, and more. GitHub is one of several such platforms (GitLab and Bitbucket are others); everything this section teaches about Git itself applies to any of them, while the "On GitHub.com" parts of each page are specific to GitHub. This distinction is explained in GitHub’s own About Git page.

In everyday use, one Git repository lives on a developer’s machine (the local repository) and a related copy lives on GitHub (a remote repository, conventionally named origin). They start out identical and then diverge as each side records its own commits, until an explicit push or pull brings them back in sync:

Repositories and Cloning and Commits explain the working directory, staging area and local repository shown above in detail.

Git 2.55 is available for every major platform. git --version confirms both that Git is installed and which release it is:

macOS — the simplest path is to run a Git command from a terminal; if the Xcode Command Line Tools are not yet installed, macOS offers to install them, which includes Git:

A more current release than the one Apple ships can be installed with the official macOS installer or a package manager such as Homebrew:

Windows — download and run the "Git for Windows" installer, which bundles the git command, Git Bash and Git Credential Manager:

Linux — install from the distribution’s package manager, which is usually close enough to current for everyday use; the project’s own download page links a repository with newer builds when it is not:

Derived from Pro Git, 1.5 Installing Git and Downloads for Git, which link the current installer for every platform.

Git stores configuration in layered files: a system-wide file, a per-user file (--global), and a per-repository file (--local, the default), with each level overriding the one before it. Two settings are required before Git will let a commit be made, because every commit records who made it:

Since Git 2.28, the name of the branch an empty repository starts on is also configurable; setting it once avoids depending on Git’s historical default of master:

The editor Git opens for commit messages, merge messages and interactive rebases defaults to the platform’s $EDITOR or the built-in fallback vi (the Git for Windows installer asks for an editor during installation, with Vim preselected); pointing it at something more familiar is a common first tweak:

One more setting worth knowing about at this stage is pull.rebase, which decides whether git pull merges or rebases the fetched commits onto the local branch — Fetch, Pull and Push explains the two behaviours and when to prefer each; there is no need to set it yet.

To confirm what is currently configured, and which file each setting came from:

Derived from Pro Git, 1.6 First-Time Git Setup.

A GitHub account is created at github.com/signup; the sign-up flow (username, email verification, and enabling two-factor authentication, which GitHub strongly recommends) is covered by GitHub’s own Creating an account on GitHub and is not repeated here.

Once an account exists, Git on the local machine needs a way to prove it is acting as that account whenever it talks to GitHub over the network (git clone, git push, git fetch/git pull against a private repository). GitHub supports two transport protocols, each with its own authentication:

HTTPS with a credential helper. Git Credential Manager (GCM) is the credential helper GitHub recommends: the first git push or git clone against a private repository over HTTPS opens a browser to sign in, and GCM then stores and refreshes the resulting credential automatically, so it is not asked for again.

HTTPS via GitHub CLI. Alternatively, gh auth login authenticates both the gh command and, when asked, Git itself for HTTPS operations:

Derived from Set up Git, Caching your GitHub credentials in Git and gh auth login.

SSH keys. Generate a modern Ed25519 key pair (RSA is still accepted but no longer recommended for new keys), protecting it with a passphrase:

Then add the public key (the .pub file, never the private one) to the account under Settings > SSH and GPG keys > New SSH key, and confirm the connection:

Derived from Connecting to GitHub with SSH.

Personal access tokens. Where neither a credential helper nor gh is available — some CI runners, some scripted environments — a personal access token can be used as the HTTPS password directly (git clone https://<your-username>@github.com/<owner>/<repo>.git, entering <TOKEN> when prompted for the password, or stored in a credential helper). Treat a token exactly like a password: never commit it, and scope and expire it as narrowly as the task allows. This is documented as the fallback, not the default, path in Set up Git.