• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Git cheat sheet

Git cheat sheet






Total Views
Views on SlideShare
Embed Views



3 Embeds 253

http://www.binary-beans.com 238
http://2501120322128564119_dbb7c8de0ae54dd6e61878b7a99ab96bb05126d3.blogspot.com 14
http://www.blog.piyushmittal.com 1



Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

    Git cheat sheet Git cheat sheet Document Transcript

    • fournova git cheat sheet presented by Tower – the most powerful Git client for Mac Create Branches & Tags Merge & RebaseClone an existing repository List all existing branches Merge <branch> into your current HEAD $ git clone ssh://user@domain.com/repo.git $ git branch $ 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 on your local Changes current HEAD Abort a rebase $ git branch <new-branch> $ git rebase --abortChanged 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 --continueChanges to tracked files  $ git branch --track <new-branch> $ git diff <remote-branch> Use your configured merge tool to solve conflictsAdd all current changes to the next Delete a local branchcommit $ git mergetool $ git branch -d <branch> $ git add . Use your editor to manually solve con- Mark the current commit with a tag flicts and (after resolving) mark file asAdd some changes in <file> to the next resolvedcommit $ git tag <tag-name> $ git add <resolved-file> $ git add -p <file> Update & Publish $ git rm <resolved-file>Commit all local changes in tracked files $ git commit -a List all currently configured remotes Undo $ git remote -vCommit previously staged changes Discard all local changes in your working $ git commit Show information about a remote directory $ git remote show <remote> $ git reset --hard HEADChange the last commitDon‘t amend published commits! Add new remote repository, named Discard local changes in a specific file$ git commit --amend <remote>  $ git checkout HEAD <file> $ git remote add <remote> <url> Revert a commit (by producing a new Download all changes from <remote>, commit with contrary changes) Commit History but don‘t integrate into HEAD $ git revert <commit> $ git fetch <remote>Show all commits, starting with newest Reset your HEAD pointer to a previous $ git log Download changes and directly merge/ commit integrate into HEAD …and discard all changes since thenShow changes over time for a specific file $ git pull <remote> <branch> $ git log -p <file> $ git reset --hard <commit> Publish local changes on a remote …and preserve all changes as unstagedWho changed what and when in <file> $ git push <remote> <branch> changes$ git blame <file> Delete a branch on the remote $ git reset <commit> $ git push <remote> :<branch> …and preserve uncommitted local changes Publish your tags $ git reset --keep <commit> $ git push --tags30-day free trial available atwww.git-tower.com the most powerful Git client for Mac
    • fournova version control best practices Commit Related Changes Test Code Before You Commit Use BranchesA commit should be a wrapper for related Resist the temptation to commit some- Branching is one of Git‘s most powerfulchanges. For example, fixing two diffe- thing that you «think» is completed. Test features - and this is not by accident:rent bugs should produce two separate it thoroughly to make sure it really is quick and easy branching was a centralcommits. Small commits make it easier completed and has no side effects (as far requirement from day one. Branches arefor other developers to understand the as one can tell). While committing half- the perfect tool to help you avoid mixingchanges and roll them back if something baked things in your local repository only up different lines of development. Youwent wrong. requires you to forgive yourself, having should use branches extensively in yourWith tools like the staging area and the your code tested is even more important development workflows: for new fea-ability to stage only parts of a file, Git when it comes to pushing/sharing your tures, bug fixes, ideas…makes it easy to create very granular code with others.commits. Commit Often Write Good Commit Messages Agree on a WorkflowCommitting often keeps your commits Begin your message with a short sum- Git lets you pick from a lot of differentsmall and, again, helps you commit only mary of your changes (up to 50 charac- workflows: long-running branches, topicrelated changes. Moreover, it allows you ters as a guideline). Separate it from branches, merge or rebase, git-flow…to share your code more frequently with the following body by including a blank Which one you choose depends on aothers. That way it‘s easier for everyone line. The body of your message should couple of factors: your project, yourto integrate changes regularly and avoid provide detailed answers to the following overall development and deploymenthaving merge conflicts. Having few large questions: workflows and (maybe most important-commits and sharing them rarely, in con- –  hat was the motivation for the change? W ly) on your and your teammates‘ personaltrast, makes it hard to solve conflicts. –  ow does it differ from the previous H preferences. However you choose to implementation? work, just make sure to agree on a com- mon workflow that everyone follows. Use the imperative, present tense («change», not «changed» or «changes») Don‘t Commit Half-Done Work to be consistent with generated messa-You should only commit code when ges from commands like git merge. Help & Documentationit‘s completed. This doesn‘t mean youhave to complete a whole, large feature Get help on the command linebefore committing. Quite the contrary: $ git help <command>split the feature‘s implementation into Version Control is not a Backup Systemlogical chunks and remember to commitearly and often. But don‘t commit just to Having your files backed up on a remote Official Git Websitehave something in the repository before server is a nice side effect of having aleaving the office at the end of the day. If http://www.git-scm.com/ version control system. But you shouldyou‘re tempted to commit just because not use your VCS like it was a backup Free online resourcesyou need a clean working copy (to check system. When doing version control, you http://progit.orgout a branch, pull in changes, etc.) consi- should pay attention to committing se- http://book.git-scm.orgder using Git‘s «Stash» feature instead. mantically (see «related changes») - you http://gitref.org shouldn‘t just cram in files.30-day free trial available atwww.git-tower.com the most powerful Git client for Mac