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 Don‘t rebase published commits!
$ git switch <branch>
$ git rebase <branch>
Create a new branch based on your
current HEAD) Abort a rebase
LOCAL CHANGES $ git branch <new-branch> $ git rebase --abort

Changed files in your working directory Continue a rebase after resolving conflicts
Create a new tracking branch based
$ git status on a remote branch $ git rebase --continue

Changes to tracked files $ git checkout --track <remote/branch> Use your configured merge tool to solve
$ git diff conflicts
Delete a local branch
$ git mergetool
Add all current changes to the next commit $ git branch -d <branch>
$ git add . Use your editor to manually solve conflicts
Mark the current commit with a tag and (after resolving) mark file as resolved
Add some changes in <file> $ git tag <tag-name> $ git add <resolved-file>
to the next commit
$ git rm <resolved-file>
$ git add -p <file>

Commit all local changes in tracked files UPDATE & PUBLISH

$ git commit -a UNDO
List all currently configured remotes
Commit previously staged changes $ git remote -v Discard all local changes in your
$ git commit working directory
Show information about a remote $ git reset --hard HEAD
Change the last commit $ git remote show <remote>
Don‘t amend published commits! Discard local changes in a specific file
$ git commit --amend Add new remote repository, $ git checkout HEAD <file>
named <remote>
$ git remote add <shortname> <url> Revert a commit (by producing a new
commit with contrary changes)
COMMIT HISTORY Download all changes from <remote>, $ git revert <commit>
but don‘t integrate into HEAD
Show all commits, starting with newest $ git fetch <remote> Reset your HEAD pointer to a previous com-
$ git log mit …and discard all changes since then
Download changes and directly merge/ $ git reset --hard <commit>
Show changes over time for a specific file integrate into HEAD
$ git log -p <file> $ git pull <remote> <branch> …and preserve all changes as unstaged
changes
Who changed what and when in <file> Publish local changes on a remote $ git reset <commit>
$ git blame <file> $ git push <remote> <branch>
…and preserve uncommitted local changes
Delete a branch on the remote $ git reset --keep <commit>
$ git push <remote> --delete <branch>

Publish your tags

$ git push --tags

30-day free trial available at

www.git-tower.com
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 something Branching is one of Git‘s most powerful
changes. For example, fixing two different that you «think» is completed. Test it tho- features - and this is not by accident: quick
bugs should produce two separate commits. roughly to make sure it really is completed and easy branching was a central requi-
Small commits make it easier for other and has no side effects (as far as one can rement from day one. Branches are the
developers to understand the changes and tell). While committing half-baked things in perfect tool to help you avoid mixing up
roll them back if something went wrong. your local repository only requires you to different lines of development. You should
With tools like the staging area and the ab- forgive yourself, having your code tested use branches extensively in your develop-
ility to stage only parts of a file, Git makes it is even more important when it comes to ment workflows:
easy to create very granular commits. pushing/sharing your code with others. for new features, bug fixes, ideas…

COMMIT OFTEN WRITE GOOD COMMIT MESSAGES AGREE ON A WORKFLOW

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

30-day free trial available at

www.git-tower.com