October 22, 2018

The GIT version control system - getting started

Git has lots of options and is very powerful, but you can do just fine ignoring most of that and working with a basic subset of commands.

Getting set up

First you need to install "git", if it is not already installed on your system. On my fedora linux system dnf install git does the job and gets git installed.

Then, on each machine on which you intend to use git (which could just be one), you should set up your identity and some preferences doing something like this: 

git config --global user.name "Abe Lincoln"
git config --global user.email abe@whitehouse.gov
git config --global core.editor "vi -f"
git config --global alias.co checkout
The last step (making "co" an alias for "checkout") is optional, I never do this or use this shortcut. It hints at the fact that you can set up a swarm of aliases for common git commands if you want to, but just ignore all of that for now, and perhaps forever.

Local and remote repositories

Git is a distributed version control system. This means that most of your work gets done with a local repository that is a mirror of some remote repository. In fact you don't need to work with a remote repository at all, and it could be quite useful to do so. This makes git both very fast and quite different from the ancient version control systems that came before it.

This is a key point with git as compared to svn for example With svn there is no local repository, only a central repository. The fact that git first works with a local repository and only pushes to a remote repository when you tell it to is what makes git a distributed version control system, and this is very much a good thing. For example, this allows you to work effectively offline and still keep a version control history.

Starting a project from a remote repository

Many people get their first introduction to git by way of the "clone" command. Someone else has been using git and has placed their project on some server (i.e. "in the cloud") and you want to get your own copy of their project. All you need is the URL to their project and you type: 
git clone URL
This creates a directory and fills it with files. It also sets up a local git repository, so you can work with these files just as if it was your own project. You won't be able to push changes back though unless you have been given permission to do so, which is pretty rare. A typical URL for the clone command might look like: 
git clone https://github.com/trebisky/Kyu.git
Other protocols besides "https" are possible, but this is the usual thing when you are cloning a read only copy of a remote repository.

Starting a project from existing files

To place an existing project under Git, you first do this: 

cd project
git init
This sets up an empty local repository. Before you put your project into it, you probably want to set up a .gitignore file which has explicit filenames and patterns for files to be excluded from git control.

To place the project under git, you do: 

git add .
git commit -m "initial"
git status
git log

The last two commands are optional "status" commands.

At this point your project is in your local repository, but has not yet been pushed to a remote repository. You might never even want to push to a remote repository, but most likely you do. That is a subject for a different section.

You could continue to work on your project and periodically issue the commands: 

git add .
git commit
And in fact that is exactly what much of the workflow with git is, making changes and periodically putting them into the local repository.
Feedback? Questions? Drop me a line!

Tom's Computer Info / tom@mmto.org