Git Cheat Sheet

Your Best Reference Pro Git -- download for PDF, ePub or Mobi formats here http://git-scm.com/book

Tip: Use Calibre's built-in server to push the ePub to your smartphone.


----------------------------------------------------------------------
Basic Git - Startup
----------------------------------------------------------------------

Basic Git Architecture

• Decentralized - everybody's copy of a project is a full database copy
• versions not stored as deltas - instead they are stored as complete instances of the files
• all content is compressed in the database

Basic Git Lifecycle

• new file => Untracked --> files unknown to Git
• 'git add' => Staged --> ready for commit, file or version not yet in database
• 'get commit' => Tracked --> file/version tracked in the database

Even Tracked files, once modified, require Staging again! i.e. you must 'git add' again!!!

Configuring Your Global Identity - Do this when first installing Git.

Set name
> git config --global user.name "Your Name"
Set email address
> git config --global user.email you@example.com

Create New Project
Create source directory. Create as a Git repo via:
> git init

Unlike SVN/CVS/VSS, the repo lives in your project directory. It's OK.
Ignore Files with .gitignore

• Put .gitignore at the project top level directory
• Add a line per filter; example:

# this is a comment
     *.class
     logs/

• this example excludes all class files, and the logs directory

----------------------------------------------------------------------
Basic Git - Typical Workflow
----------------------------------------------------------------------

See what has Changed
> git status

Commit Tracked, Modified Files
> git add -u
> git commit -m "notes about the commit"
Show changes to tracked files that are NOT staged
> git diff
Show changes to tracked files that ARE staged for commit
> git diff --staged (or --cached, an alias)

Add an Untracked File
> git add <filename>

Revert changes to a tracked file:
> git checkout -- <filename>

Revert a Staged File
It got added to stage area, but you don't want to commit it yet
> git reset HEAD <filename>

Revert all Staged Files
Unstages all from the staging area - maybe you ran 'git add .' and .gitignore did not filter properly
> git reset HEAD

Temporarily Switch to Another Branch
Got some changes not ready for committing, but need to pop to another branch - stash the current work
> git stash

Switch to another branch (git checkout)
Then come back and reapply latest stashed changes
> git stash apply

Or see list of stashes
> git stash list
And apply a named stash
> get stash apply stash@{1}

Pull Updates from a Remote Repo
Typical - when you're working with a team
- the rebase keeps the history cleaner by moving your local commits to after the new merges
> git pull --rebase

----------------------------------------------------------------------
Basic Git - Details
----------------------------------------------------------------------

Add a New File
create a README.md - this stages it
> git add README.md
and commit
> git commit -m "initial" README.md
Commit All Changed Files
Stage any changed files
> git add .
See what is staged
> git status
Commit
> git commit -m "your message"
Do all at once
> git add -A && git commit -m "your message"
Or use -a to skip staging (the 'git add' part)
> git -a -m "message"
Revert a Staged File
It got added to stage area, but you don't want to commit it yet
> git reset HEAD <filename>
Revert all Staged Files
Unstages all from the staging area
> git reset HEAD
Revert all Changes on the Branch
Don't like where the branch is going? Undo all changed files
> git checkout -f
Revert changes to a tracked file:
> git checkout -- <filename>
Revert a commit
There are myriad solutions, see here
http://stackoverflow.com/questions/927358/how-to-undo-the-last-git-commit
See What is Modified
Show any modified or untracked files
> git status
Show changes to tracked files that are NOT staged
> git diff
Show changes to tracked files that ARE staged for commit
> git diff --staged (or --cached, an alias)
Committing a File
Check for annoying whitespace changes
> git diff --check
See what changed - shows patch diffs
> git log -p filename
Commit and enter comment editor
> git commit README.md Conventional commit comment:

• 50-char summary, followed by...
• blank line, followed by...
• detailed description of change

View Commit Histories
See all changes, ever
> git log
And for a certain file
> git log -2 filename
Just the last 2 commits
> git log -2
Last commit with patch diffs
> git log -p -1
Commits since a certain date
> git log --since 1.week
> git log --since 10.days
> git log --since 2013-02-03
Commits in date range
> git log --since 2.weeks --until 1.week
Commits by committer (modifier of file)
> git log --committer username
See 'gitk' for a visual git log UI
Changing Last Commit
Add some files to the last commit. Adds whatever is staged:
> git commit --amend
Change the commit comments - assumes nothing is staged:
> git commit --amend -m "new message"
Deleting Committed Files
Just a single file, locally and from repo
> git rm filename.txt
A directory of files, locally and from repo
> git -r rm dirName
A directory of files, but ONLY from the repo, not local copies
> git -r --cached rm dirName
A file that was already staged:
> git -f filename.txt
Requires commit afterwards.
Renaming a File
Not explicitly supported internally, but calculated; and a convenience function:
> git mv oldname.txt newname.txt
Requires commit afterwards.
----------------------------------------------------------------------
Tagging
----------------------------------------------------------------------

Listing existing Tags
> git tag
Using wildcards to find tags
> git tag -l 'v1.2*'

Using a Tag
> git checkout

Creating a lightweight Tag
Example for v1.0; lightweight tags are just pointer sets
> git tag v1.0

Creating an Annotated Tag
These are checksummed and contain annotation, and optional signature
> git tag -a v1.0 -m 'release 1.0'

Creating a Signed Tag
Must have a private key installed
> git tag -s v1.0 -m 'release 1.0'

Tagging After the Fact
Forgot to tag? No matter, find the relevant commit
> git log --pretty=oneline
And tag using the checksum (first 6 or 7 characters of the checksum)
> git tag -a v1.2 9fceb02
And verify
> git show v1.2

Sharing Tags with Remotes
Tags must be pushed out like branches are
> git push origin v1.5

Or, all at once
> git push origin --tags

----------------------------------------------------------------------
Branching and Merging
----------------------------------------------------------------------

Show Current Branch
Currently checked-out branch
> git branch

List All Existing Branches
Show all branches - star is currently checked out
> git branch -v (verbose gives info on last commit)

Creating a Branch
Create new branch based on some other branch
> git checkout -b new-branch existing-branch

Create new local branch from current, and immediately check it out
> git checkout -b newbranch

Create new local branch from the remote master branch, and immediately check it out
> git checkout -b newbranch origin/master

Merge one local branch into another
This merges feature into master
> git checkout master
> git merge feature

Merge branch from remote repo into local repo
First update local copy of remote
> git fetch origin
Look at changes to remote branch
> git log origin/featureA ^featureA (not sure what the ^ is)
Merge into local branch (checkout first if necessary)
> git merge origin/featureA

Deleting a Branch
Must not be your current branch, and must not have outstanding changes
> git branch -d >branch<

----------------------------------------------------------------------
Creating a Repository on GitHub
----------------------------------------------------------------------

You created a project and want to post it to share with colleagues.
Locally you did this:

ir="ltr">create local Git repo

> git init

• Do work
• Commit files

On GitHub you do this

• Create Repo (there is a magic button)
• Note the new project URL (ending in .git)

Then locally, do this:
> git remote add origin <new git URL, ends in .git>
> git remote -v (examine your remotes)
> git push -u origin master (or whatever branch name you're working in


----------------------------------------------------------------------
Working with Remote Repositories
----------------------------------------------------------------------

A Remote is an alias to a remote repository.

Show List of Remotes
See list of known remotes
> git remote -v

Add alias to a remote repo - alias is often 'origin' by convention
> git remote add <alias> [root project URL ending in .git]

Uploading to a Remote
Upload branch contents to a named remote (origin)

Uploading a Branch to Someone Else's Repo
When branch name is the same
> git -u push <alias> <branch-name>
...example:
> git push -u origin master

When branch name is different on remote
> git -u push <alias> <local-branch-name>:<remote-branch-name>
...example:
> git -u push origin featureX:patch331

The -u option sets up a upstream branch - i.e. maps local to remote branch.

Getting changes from Remote Repo
Doing this will do a 'fetch' followed by a 'merge' - i.e. get you up to date
Pull will always merge into the current branch; specify which branch to pull from:
> git pull

Fetch is less damaging - not sure yet how to use effectively
> get fetch


----------------------------------------------------------------------
Working with GitHub Repos
----------------------------------------------------------------------

There's a project you want to get some changes into. Do this.

1. Look at the project's GitHub page; see 'Network' and 'Issues' tags.
Make sure someone else isn't already doing what you wanted to do.
2. On the GitHub page, press 'Fork' to create your own repo.
3. Clone the fork locally using its new URL
> git clone [url of my fork] <my local dir>
5. Add the fork Repo as a remote
> git remote add origin <fork URL ending in .git>
6. Add the orginal Repo as a remote for easy updating (to stay sync'd)
> git remote add upstream <original project URL ending in .git>

Contributing to Projects - Go with the Flow
Different projects may have different workflows - find out by reading the project README.
This can vary based on project size and organizer preference.

Simple Workflow Example
A simple contribution workflow looks like this:

• developer forks project
• clones fork locally ( steps 1-6 above)
• does work in topic branches - not master!
• pushes topic branches up to fork repo
• submits pull request to original project via GitHub

The Steps
1. Do initial Fork setup, steps 1-6 above

2. Create a Topic Branch
This is a branch for doing local work in
> git checkout -b new-feature origin/master

3. Keep Local work in synch
Synch with the original project - first get all its branches and updates
> git fetch upstream
Merge its change into your working branch - where 'master' is the remote branch to merge in
> git merge upstream/master

4. Do work
Do work in the topic branch ('new-feature' above) as usual
Stage and Commit when ready
Periodically merge in remote changes (#3)

5. Push changes out to your Fork repo
> git push origin new-feature

6. When Ready
Good tests are included? Bugs are out?
Log into your Github fork project and switch branches (using selector) to your new-feature branch
Verify contents; update Readme file
Navigate to original project and submit a Pull Request