Git: The Command Line

Introduction

Sadly, git in the command line is not really taught in the curriculum thoroughly, in my experience.

Git is an extremely valuable tool, used in almost every industry involving programming, and the skills are 100% transferable to other version control systems such as Perforce, which is widely used in the game design industry, as well as Mercurial and SVN, which you might find on some older projects.

Git on the command line is the first-class client, and supports every function that Git implements. GUIs such as GitHub Desktop and the one you may find in your editor, are sometimes confusing, or very basic.
However, I'm not throwing away GUI-based git clients, and there will be a section explaining some of my favorites.

Sometimes students in this class ask how would I revert changes, whether or not this will affect my changes, or how to extract a change from before, well this should explain how to do every single one of those questions and more.

This serves as a sort of personal textbook to Git, how I personally, would best explain with detail how git works, and how its functions affect your repositories.
I hope, even after this course, this serves as a valuable resource for you to look back upon.

History Of Git

Taken as an excerpt from the Git book: https://git-scm.com/book/en/v2/Getting-Started-A-Short-History-of-Git

As with many great things in life, Git began with a bit of creative destruction and fiery controversy.

The Linux kernel is an open source software project of fairly large scope. During the early years of the Linux kernel maintenance (1991–2002), changes to the software were passed around as patches and archived files. In 2002, the Linux kernel project began using a proprietary DVCS called BitKeeper.

In 2005, the relationship between the community that developed the Linux kernel and the commercial company that developed BitKeeper broke down, and the tool’s free-of-charge status was revoked. This prompted the Linux development community (and in particular Linus Torvalds, the creator of Linux) to develop their own tool based on some of the lessons they learned while using BitKeeper. Some of the goals of the new system were as follows:

• Speed

• Simple design

• Strong support for non-linear development (thousands of parallel branches)

• Fully distributed

• Able to handle large projects like the Linux kernel efficiently (speed and data size)

Since its birth in 2005, Git has evolved and matured to be easy to use and yet retain these initial qualities. It’s amazingly fast, it’s very efficient with large projects, and it has an incredible branching system for non-linear development.

Nowadays, aside from Git, we have other version control systems such as Perforce, Mercurial, Subversion, RCS, SCCS, Tortoise, and a variety of other systems. However, in my experience, aside from Perforce in the video game industry, and some old projects that still rely on Mercurial and Subversion, Git is pretty much ubiquitous.

Getting Started

The following official sites from the Git website can explain getting started with Git a lot better than me.

Installing Git:

https://git-scm.com/book/en/v2/Getting-Started-Installing-Git

First Time Git Configuration:

https://git-scm.com/book/en/v2/Getting-Started-First-Time-Git-Setup

Some things to know about setting up Git:

• A lot of users first see the error about setting up your name and email when doing any actions with Git (with John Doe as the example)

$ git config --global user.name "John Doe"

$ git config --global user.email johndoe@example.com

• The email can be your personal or Virginia Tech one, these are used for identifying commits belonging to a certain user.

• The Windows installer prompts about which editor to use along with a lot of other options, all the defaults, including Vim, are perfectly fine.

For Windows users: Everything in this guide, ideally, will be done via Git Bash, which is preinstalled with Git for Windows.

• Code blocks, like this, are most likely commands to be run inside Git Bash, and will be prefaced with a $.

Important remarks about links

If you are using Git over SSH, https:// links will not work anymore.

You can find the new link, which starts with git@github.com under the SSH tab.

All the links for Git operations in this guide will be done with the git@github.com link, but they are interchangeable with the https:// link if you do not use SSH.

The Basics

Now that we have Git installed (whew, that took a while), lets learn the basics.

Local vs Remote repositories

The most basic understanding of any distributed version control system is understanding how repositories work.

The Local repository is the directory of which your folder, managed by Git, and resides on your computer.

The Remote repository is the service of which hosts your code, managed by GitHub (or SourceHut, GitLab, or any other service), and resides on their servers.

The guide will use the terms Local and Remote, to signify different locations of where your code is.

Typically, 

Local will be your working directory, this is considered more "safe", where modifications and revisions are much more diverse and in abundance.

Remote is your submission place, this is considered more "final", as modifications and revisions here would require extra steps. So we try to keep the workflow here as clean as possible.

The Four Big Ones

The four most basic commands, dubbed "The Four Big Ones", is the most basic workflow.

If you keep your working tree clean, you can work with these four commands for the entire lifespan of the repository.

• Working tree is the various states that your repository goes through, a clean working tree means that your local to remote is successful and that your local and remote are consistent after every push.

This is the most important workflow in Git, essentially the basics:

$ git clone git@github.com:johndoe/example.git

• Download the remote repository to your local machine

$ git add *

• Add all the files that have been modified

• Although, its a much better habit to only add the files you know you edited: $ git add helloWorld.c

$ git commit -m 'Commit helloWorld'

• Commit everything that has been added, it is good practice to add a message to describes the content of your commit

• Treat this as like signing a letter, but instead of a letter, it is changes to your code

$ git push

• Push everything that has been committed, everything that you signed off on in your commit locally will be sent to your remote repository

• Treat this as like sending a letter, make sure your words are right before sending it off, however unlike letter mail, we will learn later on how to change something that has already been sent

Understanding the Four Big Ones with an example

The GitHub Git Cheatsheet

Before we go any further into Git, this cheatsheet is quintessential especially if you are stuck.

https://training.github.com/downloads/github-git-cheat-sheet.pdf