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
 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
changes. For example, fixing two different thing that you «think» is completed. Test it features - and this is not by accident: quick
bugs should produce two separate commits. thoroughly to make sure it really is completed and easy branching was a central requirement
Small commits make it easier for other de- and has no side effects (as far as one can tell). from day one. Branches are the perfect tool
velopers to understand the changes and roll While committing half-baked things in your to help you avoid mixing up different lines
them back if something went wrong. local repository only requires you to forgive of development. You should use branches
With tools like the staging area and the abi- yourself, having your code tested is even more extensively in your development workflows:
lity to stage only parts of a file, Git makes it important when it comes to pushing/sharing for new features, bug fixes, ideas…
easy to create very granular commits. 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 your deline). Separate it from the following body your project, your overall development and
code more frequently with others. That way by including a blank line. The body of your deployment workflows and (maybe most
it‘s easier for everyone to integrate changes message should provide detailed answers to importantly) on your and your teammates‘
regularly and avoid having merge conflicts. the following questions: personal preferences. However you choose to
Having few large commits and sharing them › What was the motivation for the change? work, just make sure to agree on a common
rarely, in contrast, makes it hard to solve workflow that everyone follows.
› How does it differ from the previous
conflicts.
implementation?
Use the imperative, present tense («change», HELP & DOCUMENTATION
not «changed» or «changes») to be consistent Get help on the command line
DO NOT COMMIT HALF-DONE WORK
with generated messages from commands $ git help <command>
You should only commit code when it‘s com- like git merge.
pleted. This doesn‘t mean you have
to complete a whole, large feature before
VERSION CONTROL IS NOT A BACKUP FREE ONLINE RESOURCES
committing. Quite the contrary: split the
feature‘s implementation into logical chunks SYSTEM http://www.git-tower.com/learn
and remember to commit early and often. http://rogerdudler.github.io/git-guide/
Having your files backed up on a remote
But don‘t commit just to have something in server is a nice side effect of having a version http://www.git-scm.org/
the repository before leaving the office at the control system. But you should not use your
end of the day. If you‘re tempted to commit VCS like it was a backup system. When doing
just because you need a clean working copy version control, you should pay attention to
(to check out a branch, pull in changes, etc.) committing semantically (see «related chan-
consider using Git‘s «Stash» feature instead. ges») - you shouldn‘t just cram in files.

30-day free trial available at

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