速查词典
速查表
创建
1.克隆现有仓库
git clone ssh://user@domain.com/repo.git
2.创建一个新的本地仓库
git init
本地修改
1.查看工作目录中已更改的文件，即查看 git 状态
git status
2.查看跟踪文件的更改，即远程仓库与本地仓库文件的不同
git diff
3.将所有当前更改添加到下一次提交，即全部提交
git add .
4.将某个文件的更改添加到下一次提交，即部分提交
git add -p <file>
5.提交跟踪文件中的所有本地更改
git commit -a
6.提交先前进行的更改
git commit
7.更改最后一次提交（不要修改已发布的提交）
git commit --amend
提交历史
1.显示所有提交，从最新的提交开始
git log
2.显示特定文件随时间的修改
git log -p <file>
3.查看特定文件什么时间被什么人修改了什么内容
git blame <file>
分支和标签
1.列出所有现有分支
git branch -av
2.切换当前分支
git checkout <branch>
3.基于当前 head 指针创建新分支
git branch <new-branch>
4.基于当前远程分支创建一个新跟踪分支
git checkout --track <remote/branch>
5.删除一个本地分支
git branch -d <branch>
6.将一次提交标记为一个标签
git tag <tag-name>
更新和推送
1.列出当前仓库关联的所有远程仓库
git remote -v
2.显示远程仓库的详细信息
git remote show <remote>
3.关联一个新的远程仓库到本地仓库
git remote add <shortname> <url>
4.仅拉取远程仓库所有更改，不合并到本地仓库
git fetch <remote>
5.拉取远程仓库所有更改，并合并到本地仓库
git pull <remote> <branch>
6.推送本地仓库修改到远程仓库
git push <remote> <branch>
7.删除远程仓库的一个分支
git branch -dr <remote/branch>
8.推送所有本地仓库标签到远程仓库
git push --tags
合并和变基
1.合并指定分支到当前分支
git merge <branch>
2.变基
git rebase <branch>
3.放弃变基
git rebase --abort
4.解决冲突之后继续变基
git rebase --continue
5.运行合并冲突解决工具来解决合并冲突
git mergetool
# 合并冲突解决工具需要配置，是图形化工具
6.使用编辑器手动解决冲突，并（在解决之后）将文件标记为已解决
git add <resolved-file>
git rm <resolved-file>
撤销
1.放弃工作目录中的所有本地更改
git reset --hard HEAD
2.放弃特定文件中的本地更改
git checkout HEAD <file>
3.还原提交
git revert <commit>
4.将你的 HEAD 指针重置为上一次提交...并放弃此后的所有更改
git reset --hard <commit>
5....并将所有更改保留为未提交的更改
git reset <commit>
6....并保留未提交的本地更改
git reset --keep <commit>
版本控制最佳做法
提交相关更改
提交应该是相关更改的封装。 例如，修复两个不同的BUG应产生两个单独的提交。 较小的提交可使其他开发人员更容易理解更改，并在出现问题时将其回滚。 借助暂存区和仅暂存文件部分的能力等工具，Git可以轻松创建非常精细的提交。
经常提交
经常提交会使你的提交变小，并且帮助你仅提交相关的更改。 而且，它使你可以更频繁地与他人共享代码。 这样，每个人都可以更轻松地定期同步整合代码更改，并避免合并冲突。 相比之下，很少的大量提交和共享代码，会导致很难解决冲突。
不要提交未完成的代码
你应该只能在代码完成后提交。 但这并不意味着你在提交之前必须先完成一个完整的大型功能。 恰恰相反：将功能的实现分成逻辑块，并记住要尽可能早的频繁的提交。 但是，不要只想在一天结束离开办公室之前在仓库中提交一些代码。 如果你只是因为需要干净的工作区（切换分支，同步更改等）而打算提交未完成的代码，请考虑改用git stash。
提交代码之前一定要先测试
在你还没有确认工作完成之前，忍住提交代码的冲动。彻底的测试代码，确保其没有副作用（据我们所知），虽然在本地存储库中提交半生不熟的东西只需要你原谅自己，但是当涉及到向他人推送/共享代码时，测试代码就更加重要了。
写"好"的提交注释
提交注释的开头应该要用简短的总结语句（最多 50 个字符最为开头总结），后续正文与开头用空白行分开。注释的正文应该包含下面问题的详细答案：
本次修改代码的原因是什么？
本次代码与之前的实现有何不同？
版本控制不是备份系统
在远程服务器上备份文件是版本控制系统的一个很好的副作用。但是你不应该把你的VCS（版本控制系统）当成一个备份系统来使用。在进行版本控制时，你应该注意语义上的提交(参见相关章节)——你不应该只是填入文件。
多使用分支
分支是Git最强大的功能之一，这并非偶然，因为从Git创建的第一天开始快速简单的分支就是它的中心要求。分支是帮助你避免混淆不同开发线的完美工具。你应该在开发工作流中广泛使用分支，例如，增加一个新的功能；修复BUG，新的想法等。
商定工作流程
Git允许你从许多不同的工作流中进行选择：长时间运行的分支、主题分支、合并或变基、git 流……你选择哪一个取决于几个因素：你的项目、你的整体开发和部署工作流程，以及(可能最重要的)你和你的队友的个人偏好。无论你选择如何工作，只要确保大家都同意一个通用的工作流程就可以了。
帮助与文档
在命令行获取帮助
git help <command>
免费在线资源
http://rogerdudler.github.io/git-guide/index.zh.html
https://www.git-tower.com/learn/git/ebook/cn/command-line/introduction