Git Introduction: Version Control, Setup and Branching

Jenkins, GitHub Actions, Terraform and Ansible all start from a Git repository, so Git is the foundation of every DevOps workflow. This guide explains why version control exists, how local, centralized and distributed systems differ, how Git moves a change from a workstation to GitHub, how to authenticate over HTTPS or SSH, and how teams organize branches with Gitflow. The commands themselves, with examples, are in the next part: Git Commands.

What a version control system is

A version control system (VCS) records changes to files over time. It stores every version in a dedicated database, so you can see who changed what, restore an earlier version, or discard unfinished changes.

Why it matters:

• Any earlier version of a file, or of the whole project, can be restored.
• Several developers can work on the same code at the same time and merge their changes.
• Every change is recorded with an author and a message.

Kinds of version control systems

Local version control

A local VCS keeps a version database on your own computer. Each change is stored as a patch (the difference between one version of a file and the next). This works for a single developer, but the history cannot be shared.

Centralized version control

A centralized VCS (for example SVN, CVS or Perforce) has one server that holds the official copy and full history.

• Developers check out files from the server, change them locally, and check them back in. Each check-in increases the repository version.
• Local changes are not versioned until they are checked in.
• Most operations need a connection to the server.

Drawback: both local and centralized systems have a single point of failure: the one computer or the one server. If that machine is lost, the history is lost with it. Parallel work on separate features is also harder.

Distributed version control

In a distributed VCS (for example Git or Mercurial) every developer has a complete copy of the repository, including the full history.

• You clone a repository instead of checking out files.
• Most operations are local: commit, view history, create branches. No server is needed for them.
• When the work is ready, you push it to a shared remote repository. GitHub is a popular place to host such remotes.
• Every clone is a full backup, so there is no single point of failure.

Git in short

Git is a free, open-source distributed VCS. Linus Torvalds created it in 2005 to manage the Linux kernel source code, and it is now the most widely used VCS.

• It is fast, because almost every operation runs against the local copy.
• It stores snapshots of the project rather than file differences alone.
• It supports non-linear development: many branches can grow in parallel and be merged later.

Git and GitHub are separate products. Git is the tool that runs on your machine. GitHub is a hosting service for Git repositories, with extras such as pull requests, issues and GitHub Actions.

Key terms

The Git workflow

A change moves through four places:

1. You edit files in the working directory.
2. git add copies the changes to the staging area.
3. git commit saves the staged snapshot in the local repository.
4. git push sends your commits to the remote repository. git pull brings other people's commits back to you.

Prerequisites

• A Linux machine with sudo access (the examples use Ubuntu).
• A GitHub account.

First-time setup

Install Git and set your identity

Install Git from the official download page, or on Ubuntu:

$ sudo apt update
$ sudo apt install git
$ git --version

Next, set your identity. Git records this name and email in every commit:

$ git config --global user.name "Your Name"
$ git config --global user.email "you@example.com"
$ git config --list

Connect a local project to GitHub

Create an empty repository on GitHub. On the repository page, the Code button shows two URLs: HTTPS and SSH. Anyone can clone a public repository, but pushing, or cloning a private repository, requires authentication.

The steps are identical for both URL types:

$ mkdir my-project && cd my-project
$ git init
$ echo "# my-project" > README.md
$ git add README.md
$ git commit -m "First commit"
$ git branch -M main
$ git remote add origin <repository-url>
$ git push -u origin main

git branch -M main renames the first branch to main, because older Git versions create master by default. -u links the local main to origin/main, so later git push and git pull need no arguments. To correct a wrong URL, run git remote set-url origin <new-url>.

HTTPS with a personal access token

GitHub does not accept your account password for Git over HTTPS. When Git prompts for a password, supply a personal access token (PAT) instead:

1. On GitHub, go to Settings > Developer settings > Personal access tokens.
2. Choose a token type:
   • Fine-grained tokens let you limit access to specific repositories and permissions, with an expiry date.
   • Tokens (classic) are simpler to set up, and I used one while learning. Add a note that records the token's purpose, select the scopes you need (repo for pushing code), and click Generate token.
3. Copy the token immediately. GitHub shows it only once.
4. When git push asks, enter your GitHub username and paste the token as the password.

Over HTTPS, Git prompts for the username and token on every push unless a credential helper is configured. On my own machines I use SSH instead.

SSH keys

SSH authenticates your machine with a key pair: a private key that never leaves the machine and a public key that you register with GitHub.

1. Generate a key pair. Press Enter at each prompt to accept the defaults. The keys are saved in ~/.ssh/.

   terminal

   $ ssh-keygen -t ed25519 -C "you@example.com"

   Copy command

   RSA keys (ssh-keygen -t rsa) still work, but GitHub's documentation now recommends Ed25519.

2. Print the public key and copy it. Never share the private key (id_ed25519 without .pub).

   terminal

   $ cat ~/.ssh/id_ed25519.pub

   Copy command

3. On GitHub, go to Settings > SSH and GPG keys > New SSH key and paste it.

4. Test the connection, then use the SSH URL (git@github.com:<user>/<repo>.git) as your remote:

   terminal

   $ ssh -T git@github.com
   $ git remote set-url origin git@github.com:<user>/<repo>.git

   Copy 2 commands

See the GitHub authentication docs for details on tokens and SSH keys.

Branching strategy: Gitflow

A branch isolates work on a feature from the stable code. The standard practice is to create a branch, develop and test on it, and merge it back only when it is stable. Gitflow is one popular way to organize branches. The commands to create, switch, merge and rebase branches are in Git Commands.

Main and develop

• main stores the official release history. Every commit on main is a release.
• develop is the integration branch for features. It has the complete history of the project, while main only has the release points.

Feature branches

• Each new feature gets its own branch, which can be pushed to the remote for backup and review.
• Feature branches start from develop, not from main.
• When a feature is complete, it is merged into develop. Features never interact directly with main.

Release branches

• When develop has enough features for a release, create a release branch from it.
• From that point, no new features go in: only bug fixes, documentation and other release tasks.
• When it is ready, the release branch is merged into main and tagged with a version number. It is also merged back into develop, which may have moved on.
• One team can stabilize the current release while another continues building features for the next one.

Hotfix branches

• Hotfix branches quickly patch a production release.
• They start from main instead of develop.
• When the fix is done, it is merged into both main and develop.

Key takeaways

• Git is a distributed VCS: every clone has the full history, so most work is local and there is no single point of failure.
• Changes move from working directory to staging area to local repository to remote: add, commit, push.
• Set user.name and user.email once; every commit records them.
• GitHub authenticates Git with a personal access token over HTTPS or an SSH key; SSH avoids repeated credential prompts.
• In Gitflow, features branch from develop, releases go to main with a tag, and hotfixes start from main.

Next in this series: Git Commands.