fournova

GIT CHEAT SHEET

presented by Tower - the best Git client for Mac and Windows

CREATE BRANCHES & TAGS MERGE & REBASE

Clone an existing repository List all existing branches Merge <branch> into your current HEAD 
$ git clone ssh://[email protected]/repo.git $ git branch -av $ git merge <branch>

Create a new local repository Switch HEAD branch Rebase your current HEAD onto <branch>
$ git init $ git checkout <branch> Don‘t rebase published commits!
$ git rebase <branch>
Create a new branch based
LOCAL CHANGES on your current HEAD Abort a rebase
$ git branch <new-branch> $ git rebase --abort
Changed files in your working directory
$ git status Create a new tracking branch based on Continue a rebase after resolving conflicts
a remote branch $ git rebase --continue
Changes to tracked files
$ git checkout --track <remote/branch>
$ git diff Use your configured merge tool to solve
Delete a local branch conflicts
Add all current changes to the next commit
$ git branch -d <branch> $ git mergetool
$ git add .
Mark the current commit with a tag Use your editor to manually solve conflicts
Add some changes in <file> to the next commit and (after resolving) mark file as resolved
$ git tag <tag-name>
$ git add <resolved-file>
$ git add -p <file>
$ git rm <resolved-file>
UPDATE & PUBLISH
Commit all local changes in tracked files
$ git commit -a List all currently configured remotes
$ git remote -v UNDO
Commit previously staged changes
Show information about a remote Discard all local changes in your working
$ git commit
directory
$ git remote show <remote>
Change the last commit $ git reset --hard HEAD
Don‘t amend published commits! Add new remote repository, named <remote> 
Discard local changes in a specific file
$ git commit --amend $ git remote add <shortname> <url>
$ git checkout HEAD <file>
Download all changes from <remote>, but
don‘t integrate into HEAD Revert a commit (by producing a new commit
COMMIT HISTORY
with contrary changes)
$ git fetch <remote>
Show all commits, starting with newest $ git revert <commit>
$ git log Download changes and directly
merge/integrate into HEAD Reset your HEAD pointer to a previous commit
Show changes over time for a specific file …and discard all changes since then
$ git pull <remote> <branch>
$ git log -p <file> $ git reset --hard <commit>
Publish local changes on a remote
Who changed what and when in <file> …and preserve all changes as unstaged
$ git push <remote> <branch>
$ git blame <file> changes
Delete a branch on the remote $ git reset <commit>
$ git branch -dr <remote/branch>
…and preserve uncommitted local changes
Publish your tags $ git reset --keep <commit>
$ git push --tags

30-day free trial available at

www.git-tower.com The best Git Client for Mac & Windows
 fournova

VERSION CONTROL
BEST PRACTICES

COMMIT RELATED CHANGES TEST CODE BEFORE YOU COMMIT USE BRANCHES
A commit should be a wrapper for related Resist the temptation to commit some- Branching is one of Git‘s most powerful fea-
changes. For example, fixing two different thing that you «think» is completed. Test it tures - and this is not by accident: quick and
bugs should produce two separate commits. thoroughly to make sure it really is comple- easy branching was a central requirement
Small commits make it easier for other de- ted and has no side effects (as far as one can from day one. Branches are the perfect tool
velopers to understand the changes and roll tell). While committing half-baked things to help you avoid mixing up different lines
them back if something went wrong. in your local repository only requires you of development. You should use branches
With tools like the staging area and the abi- to forgive yourself, having your code tested extensively in your development workflows:
lity to stage only parts of a file, Git makes it is even more important when it comes to for new features, bug fixes, ideas…
easy to create very granular commits. pushing/sharing your code with others.

AGREE ON A WORKFLOW

COMMIT OFTEN WRITE GOOD COMMIT MESSAGES Git lets you pick from a lot of different work-
flows: long-running branches, topic bran-
Committing often keeps your commits small Begin your message with a short summary of ches, merge or rebase, git-flow… Which one
and, again, helps you commit only related your changes (up to 50 characters as a gui- you choose depends on a couple of factors:
changes. Moreover, it allows you to share deline). Separate it from the following body your project, your overall development and
your code more frequently with others. That by including a blank line. The body of your deployment workflows and (maybe most
way it‘s easier for everyone to integrate message should provide detailed answers to importantly) on your and your teammates‘
changes regularly and avoid having merge the following questions: personal preferences. However you choose
conflicts. Having few large commits and sha- › What was the motivation for the change? to work, just make sure to agree on a com-
ring them rarely, in contrast, makes it hard to mon workflow that everyone follows.
› How does it differ from the previous
solve conflicts.
implementation?
Use the imperative, present tense («change»,
not «changed» or «changes») to be consis-
HELP & DOCUMENTATION
DO NOT COMMIT HALF-DONE WORK tent with generated messages from com-
mands like git merge. Get help on the command line
You should only commit code when it‘s com- $ git help <command>
pleted. This doesn‘t mean you have
to complete a whole, large feature before
VERSION CONTROL IS NOT A BACKUP
committing. Quite the contrary: split the
SYSTEM FREE ONLINE RESOURCES
feature‘s implementation into logical chunks
http://www.git-tower.com/learn
and remember to commit early and often. Having your files backed up on a remote
But don‘t commit just to have something http://rogerdudler.github.io/git-guide/
server is a nice side effect of having a version
in the repository before leaving the office control system. But you should not use your
http://www.git-scm.org/
at the end of the day. If you‘re tempted VCS like it was a backup system. When doing
to commit just because you need a clean version control, you should pay attention to
working copy (to check out a branch, pull in committing semantically (see «related chan-
changes, etc.) consider using Git‘s «Stash» ges») - you shouldn‘t just cram in files.
feature instead.

30-day free trial available at

www.git-tower.com The best Git Client for Mac & Windows