GIT CHEA - gitee.com

1 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 $ 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.

2 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!

3 $ 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>.

4 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 tag s $ git push --tags 30-day free trial available at 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.

5 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.

6 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.

7 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.

8 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 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 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 (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.

9 30-day free trial available at Version control with Git - made easy