Skip to main content

Quick Dictionary

AndyBinOriginalAbout 3 min

original edition

CHEAT SHEET

CREATE

1.Clone an existing repository

git clone ssh://user@domain.com/repo.git

2.Create a new local repository

git init

LOCAL CHANGES

1.Changed files in your working directory

git status

2.Changes to tracked files

git diff

3.Add all current changes to the next commit

git add .

4.Add some changes in to the next commit

git add -p <file>

5.Commit all local changes in tracked files

git commit -a

6.Commit previously staged changes

git commit

7.Change the last commit. Don‘t amend published commits!

git commit --amend

COMMIT HISTORY

1.Show all commits, starting with newest

git log

2.Show changes over time for a specific file

git log -p <file>

3.Who changed what and when in

git blame <file>

BRANCHES & TAGS

1.List all existing branches

git branch -av

2.Switch HEAD branch

git checkout <branch>

3.Create a new branch based on your current HEAD

git branch <new-branch>

4.Create a new tracking branch based on a remote branch

git checkout --track <remote/branch>

5.Delete a local branch

git branch -d <branch>

6.Mark the current commit with a tag

git tag <tag-name>

UPDATE & PUBLISH

1.List all currently configured remotes

git remote -v

2.Show information about a remote

git remote show <remote>

3.Add new remote repository, named

git remote add <shortname> <url>

4.Download all changes from , but don‘t integrate into HEAD

git fetch <remote>

5.Download changes and directly merge/integrate into HEAD

git pull <remote> <branch>

6.Publish local changes on a remote

git push <remote> <branch>

7.Delete a branch on the remote

git branch -dr <remote/branch>

8.Publish your tags

git push --tags

MERGE & REBASE

1.Merge into your current HEAD

git merge <branch>

2.Rebase your current HEAD onto , Don‘t rebase published commits!

git rebase <branch>

3.Abort a rebase

git rebase --abort

4.Continue a rebase after resolving conflicts

git rebase --continue

5.Use your configured merge tool to solve conflicts

git mergetool

6.Use your editor to manually solve conflicts and (after resolving) mark file as resolved

git add <resolved-file>
git rm <resolved-file>

UNDO

1.Discard all local changes in your working directory

git reset --hard HEAD

2.Discard local changes in a specific file

git checkout HEAD <file>

3.Revert a commit(by producing a new commit with contrary changes)

git revert <commit>

4.Reset your HEAD pointer to a previous commit...and discard all changes since then

git reset --hard <commit>

5....and preserve all changes as unstaged changes

git reset <commit>

6....and preserve uncommitted local changes

git reset --keep <commit>

VERSION CONTROL BEST PRACTICES

COMMIT RELATED CHANGES

A commit should be a wrapper for related changes. For example, fixing two different bugs should produce two separate commits. Small commits make it easier for other developers to understand the changes and roll them back if something went wrong. With tools like the staging area and the ability to stage only parts of a file, Git makes it easy to create very granular commits.

COMMIT OFTEN

Committing often keeps your commits small and, again, helps you commit only related changes. Moreover, it allows you to share your code more frequently with others. That way it‘s easier for everyone to integrate changes regularly and avoid having merge conflicts. Having few large commits and sharing them rarely, in contrast, makes it hard to solve conflicts.

DON‘T COMMIT HALF-DONE WORK

You should only commit code when it‘s completed. This doesn‘t mean you have to complete a whole, large feature before committing. Quite the contrary: split the feature‘s implementation into logical chunks and remember to commit early and often. But don‘t commit just to have something in the repository before leaving the office at the end of the day. If you‘re tempted to commit just because you need a clean working copy (to check out a branch, pull in changes, etc.) consider using Git‘s Stash feature instead.

TEST CODE BEFORE YOU COMMIT

Resist the temptation to commit some-thing that you «think» is completed. Test it thoroughly to make sure it really is completed and has no side effects (as far as one can tell). While committing halfbaked things in your local repository only requires you to forgive yourself, having your code tested is even more important when it comes to pushing/sharing your code with others.

WRITE GOOD COMMIT MESSAGES

Begin your message with a short summary of your changes (up to 50 characters as a gui-deline). Separate it from the following body by including a blank line. The body of your message should provide detailed answers to the following questions:
1.What was the motivation for the change?
2.How does it differ from the previous implementation?

VERSION CONTROL IS NOT A BACKUP SYSTEM

Having your files backed up on a remote server is a nice side effect of having a version control system. But you should not use your VCS like it was a backup system. When doing version control, you should pay attention to committing semantically (see «related chan-ges») - you shouldn‘t just cram in files.

USE BRANCHES

Branching is one of Git‘s most powerful features - and this is not by accident: quick and easy branching was a central requirement from day one. Branches are the perfect tool to help you avoid mixing up different lines of development. You should use branches extensively in your development workflows: for new features, bug fixes, ideas...

AGREE ON A WORKFLOW

Git lets you pick from a lot of different work-flows: long-running branches, topic branches, merge or rebase, git-flow... Which one you choose depends on a couple of factors: your project, your overall development and deployment workflows and (maybe most importantly) on your and your teammates‘ personal preferences. However you choose to work, just make sure to agree on a common workflow that everyone follows.

HELP & DOCUMENTATION

Get help on the command line

git help <command>

FREE ONLINE RESOURCES

https://www.git-scm.com/docsopen in new window

http://rogerdudler.github.io/git-guide/index.htmlopen in new window

https://www.git-tower.com/learn/git/ebook/en/command-line/introductionopen in new window

Last update:
Contributors: rumosky
Comments
  • Latest
  • Oldest
  • Hottest