Git 备忘录 & 版本控制最佳实践

GIT 备忘录

创建

克隆一个已存在的仓库
git clone ssh://user@domain.com/repo.git

创建一个新的本地仓库

git init

本地改动

查看工作目录中已修改的文件
git status

查看已追踪文件的改动
git diff

添加所有当前的改动到下一次提交
git add .

添加某个文件中的改动到下一次提交
git add -p <file>

提交本地已被追踪文件中的所有改动
git commit -a

提交暂存区改动
git commit

修改最后一次提交
(不要修改已经发布的提交)
git commit --amend

提交历史

显示所有提交记录，从最新的开始
git log

跟踪查看某个文件的历史修改记录
git log -p <file>

查看谁在什么时候对于某个文件的修改记录
git blame <file>

分支和标签

列出所有已存在的分支
git branch -av

切换 HEAD 分支
git checkout <branch>

基于你当前的 HEAD 创建一个新的分支
git branch <new-branch>

基于远程的分支创建一个新的追踪分支
git checkout --track <remote/branch>

删除一个本地分支
git branch -d <branch>

标记当前的提交记录为一个 tag
git tag <tag-name>

更新和发布

列出所有当前已配置的远程仓库
git remote -v

显示远程仓库的信息
git remote show <remote>

添加一个新的远程仓库
git remote add <shortname> <url>

从远程仓库下载所有的改动
（但是不会与 HEAD 合并，换而言之，需要手动合并）

git fetch <remote>

从远程仓库下载所有的改动，并且直接合并到 HEAD
git pull <remote> <branch>

发布本地改动到远程仓库
git push <remote> <branch>

在远程仓库删除一个分支
git branch -dr <remote/branch>

发布标签
git push --tags

合并与衍合

合并一个分支到你当前 HEAD
git merge <branch>

在指定的分支之上衍合你当前分支
git rebase <branch>

终止衍合
git rebase --abort

解决冲突之后，继续衍合
git rebase --continue

使用你已经配置的合并工具去解决冲突
git mergetool

使用你自己的编辑器手动解决冲突并且在解决冲突后将文件标记为已解决
git add <resolved- le>
git rm <resolved- le>

撤销

擦除工作目录中所有的改动（到最近一次提交）
git reset --hard HEAD

擦除指定文件的改动（到最近一次提交）
git checkout HEAD <file>

回退一次提交（会产生一次新的提交）
git revert <commit>

重置你的 HEAD 指针到一个之前的提交，并且此操作会擦除从那以后所有的改动
git reset --hard <commit>

重置你的 HEAD 指针到一个之前的提交，并且将所有的改动以未加入暂存区的状态保留
git reset <commit>

重置你的 HEAD 指针到一个之前的提交，并且将所有的改动以未提交的状态保留
git reset --keep <commit>

版本控制最佳实践

提交相关的改动

一次提交应该只包含相关的改动。例如：修改两个不同的 bug，应该产生两次不同的提交。 小的提交使其他开发者更容易理解所做的改动，一旦发生错误，也容易回退。暂存区和“只将部分文件暂存”的能力，让 Git 很容易创建细粒度的提交。

经常提交代码

经常提交代码能保证你每次提交的代码小巧并且帮助你每次只提交相关代码，而且，它有助于你经常和其他人分享代码。你会让其他人更好的集成你的改动，避免产生合并冲突。提交一大堆代码并且很少和其他人分享，相反的，会导致难以解决冲突。

不要提交半成品工作

你应该在代码完成后再提交。但这并不意味着你在提交之前必须先完成整个或者一个非常大的功能。 恰恰相反，将功能实现分割成一个个逻辑块然后记得及时、经常提交代码。但是不要在你下班离开办公室之前提交代码。如果你只想为了清空工作空间的改动而提交代码，那么建议你使用 Git 的 "Stash" 特性代替。

提交代码前需要进行测试

不要立即提交你认为已经完成的代码。你需要测试它，确保已经彻底的完成了并且没有副作用。在本地仓库中提交不成熟的代码你只需要原谅你自己（换句话说，一旦发布到生产环境，就需要考虑别人是否原意原谅你了），所以在你发布、和他人共享代码之前，对代码进行测试变得尤为重要。

撰写良好的提交信息

以你对本次修改的总结作为开头行，并且用一个空行分割下面的信息内容。消息内容就是需要你回答下面的问题。

1. 这次提交的动机是什么？
2. 它和之前的实现方式有什么区别？
3. 使用现在时（«change», 不是 «changed» 和 «changes»）保持和 git merge 命令产生的消息格式一致。

版本控制不是备份系统

备份你的文件到远程仓库，是 Git 带来的一个很好的副产物。但是你不应该把 Git 当做一个文件备份系统。 当你在使用版本控制工具，更关注应该是语义，而不是仅仅将文件简单粗暴的备份。

使用分支

分支是 Git 最强大的特性，简单而快速的分支是一天工作的中心。分支是一个完美的工具，帮助你避免混淆不同开发者修改的不同行。 你应该在开发工作中广泛的使用分支，用于：新特性、bug 修复、新想法等。

采用一致的工作流

Git 允许你创建大量不同的工作流，长期运行分支、话题分支、合并衍生、git-flow... ， 你选择哪一个取决于如下几个因素：项目、整体开发和部署工作流、以及可能是最重要的，你个人和团队的使用习惯。不管你选择哪种，只需要确保和其他人参与项目的人达成一致。

帮助 & 文档

通过命令行获取帮助信息

git help <command>

免费在线资源

• http://www.git-tower.com/learn
• http://rogerdudler.github.io/git-guide/
• http://www.git-scm.org/

说明

本文翻译自 git-cheatsheet.pdf

本作品采用《CC 协议》，转载必须注明作者和本文链接