A hands-on introduction to Git

Pre-installation

Mac users

Open a terminal window.
Visit https://brew.sh/. Copy and paste the command there into your terminal.

If you don’t already have a favourite text editor

Visit https://atom.io/ to download and install Atom.

What is Git?

A version-control system set up to record annotated changes to your files.
Especially suitable for text files such as LaTeX and other code.
Currently one of the most popular and supported such systems.

Why use Git when we have Dropbox?

Git has better revision history

Clearly see who changed what when.
Active control over saving revisions: avoid accidents!
Excellent support for parallel universes.
Entire history saved on the local copy.

Git is optimised for collaboration

No more conflicted copies! Edit whenever you like.
Smooth and transparent merges.
Fast synchronisation.

Installation and basic setup

Installation

Mac users: run the following in your terminal.
```
$ brew install git
    
```
Windows users: visit https://gitforwindows.org/ and download.
Linux users: install from your package manager.

First steps

Open a terminal window (or Git Bash) and check that git installed correctly.
```
$ git --version
    
```

You can get help at any time with these commands.

$ git help
$ man git
$ man git-[subcommand]

The official Git website is a fantastic resource: https://git-scm.com.

Initial setup

Let’s see what the current configuration is.
```
$ git config --list
    
```

Set up your identity.

$ git config --global user.name "Your Name"
$ git config --global user.email "Your Email"

Optionally set up some extras.

$ git config --global core.editor "atom --wait"
$ git config --global color.ui auto

Basic terminal glossary

/	<
~~~	Home directory
`cd x`	Change directory to `x`
`ls`	List contents of current directory
`cp x y`	Copy file `x` to file `y`
`mv x y`	Move/rename file `x` to file `y`
`mkdir x`	Make directory `x`
`pwd`	Print working directory

Let’s start a project!

Make the repository

Create a directory containing a new Git repository.
```
$ cd ~
$ git init testproject
    
```
Or, turn an existing directory into a Git repository.
```
$ cd [desired-directory]
$ git init
    
```
Go into this directory, and have a look around.
```
$ cd testproject
$ ls -a
$ ls .git
    
```

Some notation

Working directory: The directory containing your project files.
(Local) Git repository: The .git directory inside your working directory.
Staging area: What you’ve told Git to add to the next revision.
Commit: The act of recording the staging area as a new revision.

Changing and committing

Make the changes

Check the status of your repo. Do this often!
```
$ git status
    
```
Write a dummy LaTeX file of your choice, save, and compile.
Check the status again.
```
$ git status
    
```

Ignore unnecessary files

Visit https://github.com/asilata/.dotfiles and save the raw version of the gitignore_global file.

Move it to the correct location, and add it as the global ignore file.

$ mv ~/Downloads/gitignore_global ~/.gitignore_global
$ git config --global core.excludesFile "~/.gitignore_global"

Now see what git says.
```
$ cd ~/testproject
$ git status
    
```

Stage and commit your changes

Add your new file to the staging area. Then commit.

$ git add [name-of-your-latex-file]
$ git status
$ git commit -m "[short descriptive message]"

Have a look at what happened.
```
$ git status
$ git log
    
```
Now stage and commit a few more changes.

Undoing things

Unstaging files

Stage some more changes. You can “unstage” them before committing.
```
$ git reset --
    
```
You can also unstage individual files. Just write the filename after the command.
```
$ git add .
$ git reset -- [filename]
    
```

Throwing away unstaged/uncommitted changes

⚠ To discard unstaged changes in a single file, check out the last staged version.
```
$ git checkout -- [filename]
    
```
⚠ To throw away any uncommitted changes, do a hard reset.
```
$ git reset --hard
    
```
Safer option: stash away changes, and pop them to get them back.
```
$ git stash
$ git stash pop
    
```
Now stage and commit some more changes.

Going back in time

You can recover any of the older, committed versions of your files.

To do this, you can “check out” a file from an older commit.

$ git log --oneline
$ git checkout [commit] [filename]

To throw away the changes you (re-)introduced, do a hard reset again.

Working with remotes

Remote (repository): An external Git repository that your local repository connects to and syncs with.

Connecting to remotes

You can host a remote on service such as GitHub, BitBucket, or GitLab.
You can either clone an existing remote repo to make a local repo, or copy over your local repo to a remote hosting service.
We’ll do both today, working with GitHub. The other services are very similar.

Connecting to GitHub with ssh

Create an account at https://github.com/.
Check for existing ssh keys.
```
$ ls -al ~/.ssh
    
```
If you don’t see any, generate a new one first. This command creates one with an empty passphrase.
```
$ ssh-keygen -t rsa -b 4096 -C "[your email]" -P ""
    
```
Detailed instructions are at https://help.github.com/articles/connecting-to-github-with-ssh/.

Connecting to GitHub with ssh (continued)

Open your public key file with your favourite text editor.
```
$ atom ~/.ssh/id_rsa.pub &
    
```
Navigate to GitHub > Settings > SSH and GPG keys > New SSH key and copy and paste the contents of the key file there.
Test your connection.
```
$ ssh -T git@github.com
    
```

Let’s host our project on GitHub

Create your GitHub remote repo

Hit + in the top right corner of your GitHub account, and then New repository.
Call it whatever you like and hit Create repository.

Now go to your project and add GitHub as a remote.

$ cd ~/testproject
$ git remote add origin git@github.com:[username]/testproject.git
$ git remote -v

More about remotes and pushing

origin: The conventional name for your default remote repository.
Push: The act of sending the changes you committed to your local repository to your remote repository.

Pushing to your default remote

Unlike a commit, you don’t write a message when you push.
The first time, you need to specify that you’re pushing your “master” branch to the “origin” remote.
```
$ git push -u origin master
    
```
Afterwards you can just push.
```
$ git push
    
```

Collaboration and conflicts

Some more notation

Cloning: Getting a full copy of a remote repository as your local repository.
Push access: Whether you have permission to push onto a repo you cloned. Usually you don’t!

Find a partner and add them to your repo

Player 1

Navigate to your GitHub repository and then to Settings > Collaborators.
Add your partner — gives them push access.

Player 2

Navigate to the repository.
Under Clone or download, select Clone with SSH.

Copy the address given, and clone it.

$ git clone [address] [repo-name]
$ cd [repo-name]

Create some divergence

Modify different parts of the same file, stage, and commit. Then try to push.
Git will complain to the second person who tries to push.

In order to push, pull first

The remote rejected your changes because your repo was not in sync.
Fetch and merge first. Git will “fast-forward merge”.
```
$ git fetch
$ git merge
    
```
There is a single command to accomplish the above.
```
$ git pull
    
```

Create some conflict

Now modify the same part of a single file, stage and commit.
Again, try to push, and note that Git complains to the second person.
Pull (or fetch and merge) again. This time, Git will complain about a conflict. Don’t panic!

Fixing conflicts

See which files need work.
```
$ git status
    
```
Open the file(s) listed in your text editor. You will see some conflict markers, such as below.
```
<<<<<<< HEAD
Hello, world!
=======
Hello, universe!
>>>>>>> origin/master
    
```
Keep the version you like, or mix and match. Delete the conflict markers. Do this at every conflicted section, then save.

Fixing conflicts (continued)

Now add all the files again.
```
$ git add .
    
```

Then commit as usual, and push if you like.

$ git commit -m "Fixed conflict in the greeting."
$ git push

Branching

Branches are parallel universes of your project.

Any work you do in Git happens in some branch. The default one you start off with is called “master”.
```
$ git branch
    
```
If you want to work on your own for a bit without messing up the default branch, you can make a new branch.
Branching is very fast in Git, so use it extensively!

Creating and working with branches

The plain git branch command lists all the branches, but you can also use it to create a new branch.
```
$ git branch testing
$ git branch
$ git checkout testing
$ git branch
    
```
Go ahead and commit some changes in the new branch. It doesn’t affect the master branch.
```
$ git log --oneline
$ git checkout master 
$ git log --oneline
    
```

Merging changes

If you’re happy with your tests and want to put them in the master branch, you can merge them back in.
```
$ git checkout master
$ git merge testing
$ git log --oneline
    
```

Forking (GitHub-specific)

Usually you can’t push to other people’s repositories in GitHub.
If you ‘Fork’ someone’s repo, it gets copied (cloned) over to your GitHub page.
Now you can add it as a remote and push to it.

Git clients

There are lots of Git clients out there. Try out a few, and select the one that works best for you.
Here are just a few of the available options.
- The git-control package — manage git within atom.
- Sourcetree, GitHub desktop — GUI clients for Mac and Windows.
- Git Kraken — GUI client; works on Linux as well.
- Magit — a Git interface within Emacs. My personal favourite!

Further references

Try an interactive tutorial at your own pace: https://github.com/jlord/git-it-electron.
Read this visual git guide: https://marklodato.github.io/visual-git-guide/.
Read the Pro Git book: https://git-scm.com/book.
Read the manuals! They are fantastic.
The source for this presentation is available at https://github.com/asilata/gitworkshop.

FilesExpand file tree

git-workshop.org

Latest commit

History