Git and GitHub

Overview

Associate Professor Justin Dressel

Schmid College of Science and Technology

 

git

  • Written by the creator of Linux, Linus Torvalds
  • Distributed change control system - no client-server model
  • Allows fast off-line patch-based code change management

According to README in git source code:

The name "git" was given by Linus Torvalds when he wrote the very
first version. He described the tool as "the stupid content tracker"
and the name as (depending on your mood):

 - random three-letter combination that is pronounceable, and not
   actually used by any common UNIX command.  The fact that it is a
   mispronunciation of "get" may or may not be relevant.
 - stupid. contemptible and despicable. simple. Take your pick from the
   dictionary of slang.
 - "global information tracker": you're in a good mood, and it actually
   works for you. Angels sing, and a light suddenly fills the room.
 - "goddamn idiotic truckload of sh*t": when it breaks

Idea of git

What if more than one coder works on the same project?

How can source code be synchronized in a sensible way?

Work Area

Staging Area

Public Record

Hack at code here.

Changes visible only to you.

Where ideas are tested and made to work properly.

Finished changes stored here.

Prettier version of work area, with ugly bits skipped.

Still private.

Key insight: Organize code into repositories that record logical change sets that can then be synchronized and merged with other changes

git REPOSITORY

add

commit

Stores recorded public patches.

Logical sets of changes.

Synchronized as whole units.

Pulling changes

Repository A

Patch 1

Repository B

Patch 2

git pull

Repository A

Patch 1

Repository B

Patch 2

Before:

After:

Repository A

Patch 2

Pulling patches from another repository adds those sets of changes to yours.

Pushing changes

Repository A

Patch 1

Repository B

Patch 2

git push

Repository A

Patch 1

Repository B

Patch 2

Before:

After:

Repository A

Patch 1

Pushing patches to another repository adds those sets of changes to theirs.

Patch 2

Patch 2

Resolving Conflicts

Repository A

Patch 1

Repository B

Patch 2

git pull

Repository A

Patch 1&2

Repository B

Patch 2

Before:

Repository A

If patches have changes that conflict then you must choose how to edit the two versions to resolve the conflict after a pull

Then you can push the fix

git push

Typical Workflow

~$ git clone username@computer:/path/to/git/repository.git
# This creates a clone (copy) of a remote git repository 
# (using SSH if needed: see next few slides)

~$ cd repository
# Change to repository directory to commence work

<work on stuff here>

~/repository$ git add file1 file2 file3
# After you are satisfied with some changes, add the 
# changed files to the "staging area"

~/repository$ git commit -m "Description of new patch"
# Create a new patch from all changes added to the
# staging area, including a description of that set of
# changes as a logically complete addition to the code

# TIP: Try not to make commits that have syntax errors
# or obvious errors. Think of commits as finished 
# changes that you are ready for others to read.

~/repository$ git pull
# Check that you are up-to-date with the remote repo

~/repository$ git push
# Push your new committed patch(es) to the remote repo

clone

add

commit

pull

push

(do work)

Misc git tips

Global user settings:

~$ git config --global user.name "Your Full Name"
~$ git config --global user.email "yourname@email.domain"
~$ git config --global push.default simple
~$ git config --global core.editor vim

(vim is the recommended editor: it is almost everywhere and powerful)

Other useful commands:

 

~$ git status -s
# Look at current state of repository
# TIP: USE THIS OFTEN to figure out what's going on

~$ git log
# Look at list of all committed patches

~$ git diff filename
# See unadded changes in filename

~$ git diff origin/master filename
# See changes from remote repo in filename

~$ git grep "search string"
# Find instances of "search string" in code

##
### If you screw up:
##

~$ git checkout -- filename
# Restore last committed version of modified filename

~$ git fetch origin
~$ git reset --hard origin/master
# obliterate all recent changes
# resets entire repository to last remote repository state
# TIP: Use this only as a last resort after a big screwup

status

log

diff

grep

checkout

fetch

reset

GitHub

GitHub is a central server that hosts git repositories in the cloud for the open source community

Patch 1

Repository

Patch 1

git clone

git pull

git push

Repository

GitHub

Repository

Patch 1

This makes it easy for multiple coders to work on the same master code base

Remote SSH Connections

Creating SSH Keys:

  • Run the command:
       (Press enter 3 times to select default options, with no need to type a password)
  • This generates a "secure shell" private/public (RSA) key pair
  • These keys "unlock" remote shell access between linux computers
  • You need to do this so that your computer can talk to GitHub directly
~$ if [ ! -e ~/.ssh/id_rsa.pub ]; then ssh-keygen; fi

Adding SSH keys to GitHub:

  • Run the command:   
  • Copy the output (your public key) starting with "ssh-rsa ..."
  • Log into your GitHub account
  • In GitHub, go to Settings -> SSH Keys and add your new key
     
  • Back in your terminal, run: 
  • Make sure GitHub welcomes your username, then exits
    (GitHub does not allow using the shell, just git file transfers)
~$ cat ~/.ssh/id_rsa.pub
~$ ssh git@github.com

(More about ssh)

Further Reading

Practice makes perfect.

 

Keep references handy until you remember commands on command.