国外网友制作的Git Cheat Sheet，已经翻译为中文，描述了常用的Git命令和使用git的最佳做法
我对翻译后的文案加上序号和格式的调整
建议记下它们，如果你使用git
一、常见命令
1. 创建
克隆现有的存储库
$ git clone ssh://[email protected]/repo.git
创建新的本地存储库
$ git init
2. 本地变化
更改工作目录中的文件
$ git status
对跟踪文件的更改
$ git diff
将所有当前更改添加到下一次提交
$ git add .
将< file >中的一些更改添加到下一次提交
$ git add -p <file>
提交跟踪文件中的所有本地更改
$ git commit -a
提交先前阶段的更改
$ git commit
更改最后提交
不要修改发布的提交！
$ git commit --amend
3. 提交历史
显示所有提交，从最新开始
$ git log
显示特定文件随时间的变化
$ git log -p <file>
谁在< file >中更改了内容和时间？
$ git blame <file>
4. 分支和标签
列出所有现有分支
$ git branch -av
切换分支
$ git checkout <branch>
根据当前的头部创建一个新分支
$ git branch <new-branch>
基于远程分支创建新的跟踪分支
$ git checkout --track <remote/bran- ch>
删除本地分支
$ git branch -d <branch>
提交标签
$ git tag <tag-name>
5. 更新和发布
列出所有当前配置的遥控器
$ git remote -v
显示有关远程
$ git remote show <remote>
添加名为< Remote >的新远程存储库
$ git remote add <shortname> <url>
从< Remote >下载所有更改，但不要集成到Head中
$ git fetch <remote>
下载更改并直接合并/集成到头中
$ git pull <remote> <branch>
在远程上发布本地更改
$ git push <remote> <branch>
删除远程上的分支
$ git branch -dr <remote/branch>
发布标签
$ git push --tags
6. 合并和重基
将<分支>合并到当前的头部
$ git merge <branch>
将当前的头重新定位到<分支>
不要重新发布已发布的提交！
$ git rebase <branch>
中止重基
$ git rebase --abort
解决冲突后继续重基
$ git rebase --continue
使用配置的合并工具解决冲突
$ git mergetool
使用编辑器手动解决冲突，并(在解决后)将文件标记为“已解决”。
$ git add <resolved-file>
$ git rm <resolved-file>
7. 撤销
放弃工作目录中的所有本地更改。
$ git reset --hard HEAD
放弃特定文件中的本地更改。
$ git checkout HEAD <file>
还原一个提交(通过产生一个新的具有相反更改的提交)
$ git revert <commit>
将头指针重置为上一次提交
…并放弃自那以后的所有变化
$ git reset --hard <commit>
…并将所有更改保留为未分阶段的更改。
$ git reset <commit>
…并保存未提交的本地更改。
$ git reset --keep <commit>
二、最佳做法
1. 提交相关修改
提交应该是相关更改的包装。例如，修复两个不同的bug应该产生两个单独的提交。消息使其他开发者更容易理解禅宗。 如果出了什么问题就把它们退回去。
有了诸如分阶段区域和ABI特性这样的工具，只对文件的部分进行分级，Git使创建非常细粒度的提交变得非常容易。
2. 经常提交
提交经常使您的承诺保持较小，并且再次帮助您仅提交相关的更改。
此外，它允许您更频繁地与其他人共享代码。
这样对每个人来说都比较容易 定期集成更改，避免合并冲突。
相反，很少有大量的提交，并且很少分享它们，这使得解决冲突变得困难。
3. 不要半途而废
您应该只在代码完成时提交代码。这并不意味着您必须在提交之前完成一个完整的大型功能。完全相反：分裂
特性的实现分为逻辑块，并记住要尽早提交。
但是，不要只承诺在一天结束前离开办公室之前就在存储库中有一些东西。如果仅仅因为需要一个干净的工作副本(检查分支)而想提交 在变化，拉等）考虑使用Git的«stash»特征相反。
4. 在提交之前测试代码
抵制诱惑，去做一些你认为已经完成的事情。彻底测试它，以确保它真的完成了。
而且没有副作用(据我们所知)。虽然在本地存储库中提交半生不熟的东西只需要您原谅自己，但是在以下情况下进行代码测试就更重要了。 这涉及到推送/与他人共享代码。
5. 编写良好的提交消息
开始您的消息，以一个简短的总结，您的变化(多达50个字符作为一个Gui-deline)。将它与下面的正文分隔开，方法是包含一个空行。您的消息正文应该提供如以下问题的邮件式解答：
改变的动机是什么？
它与以前的实施方式有何不同？
使用祈使句、现在时态（省去变化、不改变或改变）与来自Git合并的命令生成的消息一致。
6. 版本控制不是备份系统。
在远程服务器上备份文件是拥有版本控制系统的一个很好的副作用。但是你不应该像使用备份系统一样使用你的VCS。在执行版本控制时，您将应该注意语义上的（见相关的Chan-Ges）-你不应该只是在文件中填塞。
7. 使用分支
分支是Git最强大的特性之一，这不是偶然的：快速和容易的分支是第一天的中心要求。分支是帮助你避免混淆不同发展方向的完美工具. 您应该在开发工作流程中广泛使用分支：用于新特性、bug修复、想法……
8. 就工作流达成一致
git允许您从许多不同的工作流中选择：长时间运行的分支、主题bran-ch、合并或重基、git-flow…。您选择哪一个取决于以下几个因素：你的项目，你的整体开发和部署工作流程，（也许最重要的）是你和你的队友的个人喜好。无论你选择工作，只要确保达成一个共同的工作流程，每个人都遵循这个工作流程。
9. 使用帮助和文档
获取命令行的帮助
$ git help <command>
免费在线资源
http://www.git-tower.com/learn
http://rogerdudler.github.io/git-guide/
http://www.git-scm.org/