Git Cheat Sheet——Git的常用命令和最佳做法

国外网友制作的Git Cheat Sheet，已经翻译为中文，描述了常用的Git命令和使用git的最佳做法
我对翻译后的文案加上序号和格式的调整
建议记下它们，如果你使用git

一、常见命令

1. 创建

克隆现有的存储库

 $ git clone ssh://user@domain.com/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/