Git and GitHub
Overview
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
Further Reading
Practice makes perfect.
Keep references handy until you remember commands on command.
Git and GitHub Overview
By Justin Dressel
Git and GitHub Overview
These slides offer a condensed description of the essentials of using git and GitHub to manage an open-source code-base.
- 3,726