git

A Guide to git

Version Control

git is a version control system invented by Linus Torvalds as tool to facilitate development of his namesake operating system kernel, Linux.

Version control is exactly what it sounds like: it lets you keep track of the changes in a codebase. It is extremely flexible, allowing you to branch and merge version timelines, annotate changes, collaborate with others, maintain and merge distributed databases on remote servers, and more.

There are two aspects to this guide:

I will give suggestions of how to use git as an example and to illustrate how git works, but the beauty of git is that it is meant to be flexible to different workflows, and its philosophy is that you can use it however you like.

Installation

Github is an online hosting platform for git repositories. You can create a free account to get started.

Regardless of whether you use GitHub, you’ll want to install git locally on your system. This is a good guide (from the official git website): https://git-scm.com/book/en/v2/Getting-Started-Installing-Git

For newcomers to computer programming and those who have never used the command line interface on their computers, git can be intimidating and confusing.

https://xkcd.com/1597/

A good place to start instead is with GitHub Desktop, a GUI interface for most of the basic features of git (certainly all you will need for now).

The Atom text editor (from GitHub) has git (and GitHub) integration.

This list of git GUI applications: https://git-scm.com/downloads/guis

The convenience is that all of these GUI apps are like frontends while the backend, git, stays the same. They can be replaced with one another (and even used in tandem) seamlessly.

Learning Resources

These are some things that I have come across that are at least somewhat helpful. I’ll be updating this as I discover more.

Basics

Git version controls a folder that’s called a repository. A locally-stored (on your computer rather than the cloud) repository is identified by having a .git (possibly hidden) folder in it, where all of the git data (history, branches, etc) are stored.

There are: commits, stashes, branches, tags, blobs, a HEAD, an index, remotes, …

Commits

The history of changes is broken down into commits, which are snapshots of the state of the repository at a particular time. (don’t worry, git is very efficient about compressing the history, it only stores the differences) Commits should represent a single atomic change, one that cannot be broken down further. A typical rule of thumb for the size of a git commit is 5-10 lines of code.

Each commit has some nonnegative number of parents, commits that come immediately before it in the history. The initial commit has zero parents, normal commits have one, and merge commits have two (or more).

Each commit has a hash value, a long hexadecimal identifier which uniquely identifies it among all commits everywhere in the universe (there is a probability of hash collision, but it is astronomically small).

Commit Message

Each commit comes with a message: a (required) one-line summary of what the changes mean and/or why they were done, and an (optional) multi-line (or multi-paragraph) description going into more detail.

Writing good messages is essential. Follow the 50/72 rule. Summaries should start with a capitalized word (preferably a verb like “Add”, “Drop”, “Fix”, or “Refactor”), be written in present tense, and end without punctuation.

https://xkcd.com/1296/

Stashes

more to come…

Branches

Branches are references to particular commits which can be updated with new commits on top of it.

Tags

Tags are like branches, except they are meant to remain fixed. They may refer to specific released versions etc.

Checkout and Head

more to come…

Remote

more to come…

Reviewing History

more to come…

Fixing Mistakes (how to get out of trouble)

  1. Commit onto wrong branch

    more to come…

  2. Add changes to a previous commit

    more to come…