Scribd
Upload
140 views

Git Cheatsheet EN Grey PDF

This document provides a cheat sheet for using Git version control. It outlines commands for creating and cloning repositories, tracking changes, branching, merging, rebasing, undoing changes, and viewing commit history. It also offers best practices for structuring commits, testing code before committing, using branches extensively, committing often with small changes, avoiding half-finished work, and writing clear commit messages.

Uploaded by

Carlos Ivan Castro
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
140 views

Git Cheatsheet EN Grey PDF

This document provides a cheat sheet for using Git version control. It outlines commands for creating and cloning repositories, tracking changes, branching, merging, rebasing, undoing changes, and viewing commit history. It also offers best practices for structuring commits, testing code before committing, using branches extensively, committing often with small changes, avoiding half-finished work, and writing clear commit messages.

Uploaded by

Carlos Ivan Castro
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 2

fournova

GIT CHEAT SHEET


›
presented by TOWER Version control with Git - made easy

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/bran-
$ git diff ch> Use your configured merge tool to
solve conflicts
Add all current changes to the next commit Delete a local branch
$ git mergetool
$ git add . $ git branch -d <branch>
Use your editor to manually solve conflicts
Add some changes in <file> to the next commit Mark the current commit with a tag and ( after resolving) mark file as resolved
$ git add -p <file> $ git tag <tag-name> $ git add <resolved-file>
Commit all local changes in tracked files $ git rm <resolved-file>
$ git commit -a UPDATE & PUBLISH
Commit previously staged changes List all currently configured remotes UNDO
$ git commit $ git remote -v
Discard all local changes in your working
Change the last commit Show information about a remote directory
Don‘t amend published commits! $ git remote show <remote> $ git reset --hard HEAD
$ git commit --amend
Add new remote repository, named <remote>  Discard local changes in a specific file
$ git remote add <shortname> <url> $ git checkout HEAD <file>
COMMIT HISTORY
Download all changes from <remote>, Revert a commit (by producing a new commit
Show all commits, starting with newest but don‘t integrate into HEAD with contrary changes)
$ git log $ git fetch <remote> $ git revert <commit>

Show changes over time for a specific file Download changes and directly Reset your HEAD pointer to a previous commit
$ git log -p <file> merge/integrate into HEAD …and discard all changes since then
$ git pull <remote> <branch> $ git reset --hard <commit>
Who changed what and when in <file>
$ git blame <file> Publish local changes on a remote …and preserve all changes as unstaged
$ git push <remote> <branch> changes
$ git reset <commit>
Delete a branch on the remote
$ git branch -dr <remote/branch> …and preserve uncommitted local changes
$ git reset --keep <commit>
Publish your tags
$ git push --tags

30-day free trial available at


www.git-tower.com Version control with Git - made easy
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
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
easy to create very granular commits. important when it comes to pushing/sharing for new features, bug fixes, ideas…
your code with others.

COMMIT OFTEN WRITE GOOD COMMIT MESSAGES AGREE ON A WORKFLOW


Committing often keeps your commits small Begin your message with a short summary of Git lets you pick from a lot of different work-
and, again, helps you commit only related your changes (up to 50 characters as a gui- flows: long-running branches, topic bran-
changes. Moreover, it allows you to share your deline). Separate it from the following body ches, merge or rebase, git-flow… Which one
code more frequently with others. That way by including a blank line. The body of your you choose depends on a couple of factors:
it‘s easier for everyone to integrate changes
message should provide detailed answers to your project, your overall development and
regularly and avoid having merge conflicts.
the following questions: deployment workflows and (maybe most
Having few large commits and sharing them
›› What was the motivation for the change? importantly) on your and your teammates‘
rarely, in contrast, makes it hard to solve
conflicts. personal preferences. However you choose to
›› How does it differ from the previous work, just make sure to agree on a common
implementation? workflow that everyone follows.
DON‘T COMMIT HALF-DONE WORK Use the imperative, present tense («change»,
You should only commit code when it‘s not «changed» or «changes») to be consistent
HELP & DOCUMENTATION
completed. This doesn‘t mean you have with generated messages from commands
to complete a whole, large feature before like git merge. Get help on the command line
committing. Quite the contrary: split the $ git help <command>

feature‘s implementation into logical chunks


VERSION CONTROL IS NOT
and remember to commit early and often.
A BACKUP SYSTEM FREE ONLINE RESOURCES
But don‘t commit just to have something in
http://www.git-tower.com/learn
the repository before leaving the office at the Having your files backed up on a remote
end of the day. If you‘re tempted to commit http://rogerdudler.github.io/git-guide/
server is a nice side effect of having a version
just because you need a clean working copy control system. But you should not use your http://www.git-scm.org/
(to check out a branch, pull in changes, etc.) VCS like it was a backup system. When doing
consider using Git‘s «Stash» feature instead. version control, you should pay attention to
committing semantically (see «related chan-
ges») - you shouldn‘t just cram in files.

30-day free trial available at


www.git-tower.com Version control with Git - made easy

You might also like