中文版

速查表

创建

• 克隆现有仓库

git clone ssh://user@domain.com/repo.git

• 创建一个新的本地仓库

git init

本地修改

• 查看工作目录中已更改的文件，即查看git状态

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

• 切换当前分支

git checkout <branch>

• 基于当前head指针创建新分支

git branch <new-branch>

• 基于当前远程分支创建一个新跟踪分支

git checkout --track <remote/branch>

• 删除一个本地分支

git branch -d <branch>

• 将一次提交标记为一个标签

git tag <tag-name>

更新和推送

• 列出当前仓库关联的所有远程仓库

git remote -v

• 显示远程仓库的详细信息

git remote show <remote>

• 关联一个新的远程仓库到本地仓库

git remote add <shortname> <url>

• 仅拉取远程仓库所有更改，不合并到本地仓库

git fetch <remote>

• 拉取远程仓库所有更改，并合并到本地仓库

git pull <remote> <branch>

• 推送本地仓库修改到远程仓库

git push <remote> <branch>

• 删除远程仓库的一个分支

git branch -dr <remote/branch>

• 推送所有本地仓库标签到远程仓库

git push --tags

合并和变基

• 合并指定分支到当前分支

git merge <branch>

• 变基

git rebase <branch>

• 放弃变基

git rebase --abort

• 解决冲突之后继续变基

git rebase --continue

• 运行合并冲突解决工具来解决合并冲突

git mergetool
# 合并冲突解决工具需要配置，是图形化工具

• 使用编辑器手动解决冲突，并（在解决之后）将文件标记为已解决

git add <resolved-file>
git rm <resolved-file>

撤销

• 放弃工作目录中的所有本地更改

git reset --hard HEAD

• 放弃特定文件中的本地更改

git checkout HEAD <file>

• 还原提交

git revert <commit>

• 将你的HEAD指针重置为上一次提交…并放弃此后的所有更改

git reset --hard <commit>

• …并将所有更改保留为未提交的更改

git reset <commit>

• …并保留未提交的本地更改

git reset --keep <commit>

版本控制最佳做法

提交相关更改

提交应该是相关更改的封装。 例如，修复两个不同的BUG应产生两个单独的提交。 较小的提交可使其他开发人员更容易理解更改，并在出现问题时将其回滚。 借助暂存区和仅暂存文件部分的能力等工具，Git可以轻松创建非常精细的提交。

经常提交

经常提交会使你的提交变小，并且帮助你仅提交相关的更改。 而且，它使你可以更频繁地与他人共享代码。 这样，每个人都可以更轻松地定期同步整合代码更改，并避免合并冲突。 相比之下，很少的大量提交和共享代码，会导致很难解决冲突。

不要提交未完成的代码

你应该只能在代码完成后提交。 但这并不意味着你在提交之前必须先完成一个完整的大型功能。 恰恰相反：将功能的实现分成逻辑块，并记住要尽可能早的频繁的提交。 但是，不要只想在一天结束离开办公室之前在仓库中提交一些代码。 如果你只是因为需要干净的工作区（切换分支，同步更改等）而打算提交未完成的代码，请考虑改用git stash。

提交代码之前一定要先测试

在你还没有确认工作完成之前，忍住提交代码的冲动。彻底的测试代码，确保其没有副作用（据我们所知），虽然在本地存储库中提交半生不熟的东西只需要你原谅自己，但是当涉及到向他人推送/共享代码时，测试代码就更加重要了。

写”好”的提交注释

提交注释的开头应该要用简短的总结语句（最多50个字符最为开头总结），后续正文与开头用空白行分开。注释的正文应该包含下面问题的详细答案：

本次修改代码的原因是什么？本次代码与之前的实现有何不同？

版本控制不是备份系统

在远程服务器上备份文件是版本控制系统的一个很好的副作用。但是你不应该把你的VCS（版本控制系统）当成一个备份系统来使用。在进行版本控制时，你应该注意语义上的提交(参见相关章节)——你不应该只是填入文件。

多使用分支

分支是Git最强大的功能之一，这并非偶然，因为从Git创建的第一天开始快速简单的分支就是它的中心要求。分支是帮助你避免混淆不同开发线的完美工具。你应该在开发工作流中广泛使用分支，例如，增加一个新的功能；修复BUG，新的想法等。

商定工作流程

Git允许你从许多不同的工作流中进行选择：长时间运行的分支、主题分支、合并或变基、git流……你选择哪一个取决于几个因素：你的项目、你的整体开发和部署工作流程，以及(可能最重要的)你和你的队友的个人偏好。无论你选择如何工作，只要确保大家都同意一个通用的工作流程就可以了。

帮助与文档

在命令行获取帮助

git help <command>

免费在线资源

https://www.git-scm.com/docshttp://rogerdudler.github.io/git-guide/index.zh.htmlhttps://www.git-tower.com/learn/git/ebook/cn/command-line/introduction

英文版（原版）

CHEAT SHEET

CREATE

• Clone an existing repository

git clone ssh://user@domain.com/repo.git

• Create a new local repository

git init

LOCAL CHANGES

• Changed files in your working directory

git status

• Changes to tracked files

git diff

• Add all current changes to the next commit

git add .

• Add some changes in to the next commit

git add -p <file>

• Commit all local changes in tracked files

git commit -a

• Commit previously staged changes

git commit

• Change the last commitDon‘t amend published commits!

git commit --amend

COMMIT HISTORY

• Show all commits, starting with newest

git log

• Show changes over time for a specific file

git log -p <file>

• Who changed what and when in

git blame <file>

BRANCHES & TAGS

• List all existing branches

git branch -av

• Switch HEAD branch

git checkout <branch>

• Create a new branch based on your current HEAD

git branch <new-branch>

• Create a new tracking branch based on a remote branch

git checkout --track <remote/branch>

• Delete a local branch

git branch -d <branch>

• Mark the current commit with a tag

git tag <tag-name>

UPDATE & PUBLISH

• List all currently configured remotes

git remote -v

• Show information about a remote

git remote show <remote>

• Add new remote repository, named

git remote add <shortname> <url>

• Download all changes from , but don‘t integrate into HEAD

git fetch <remote>

• Download changes and directly merge/integrate into HEAD

git pull <remote> <branch>

• Publish local changes on a remote

git push <remote> <branch>

• Delete a branch on the remote

git branch -dr <remote/branch>

• Publish your tags

git push --tags

MERGE & REBASE

• Merge into your current HEAD

git merge <branch>

• Rebase your current HEAD onto , Don‘t rebase published commits!

git rebase <branch>

• Abort a rebase

git rebase --abort

• Continue a rebase after resolving conflicts

git rebase --continue

• Use your configured merge tool to solve conflicts

git mergetool

• Use your editor to manually solve conflicts and (after resolving) mark file as resolved

git add <resolved-file>
git rm <resolved-file>

UNDO

• Discard all local changes in your working directory

git reset --hard HEAD

• Discard local changes in a specific file

git checkout HEAD <file>

• Revert a commit(by producing a new commit with contrary changes)

git revert <commit>

• Reset your HEAD pointer to a previous commit…and discard all changes since then

git reset --hard <commit>

• …and preserve all changes as unstaged changes

git reset <commit>

• …and preserve uncommitted local changes

git reset --keep <commit>

VERSION CONTROL BEST PRACTICES

COMMIT RELATED CHANGES

A commit should be a wrapper for related changes. For example, fixing two different bugs should produce two separate commits. Small commits make it easier for other developers to understand the changes and roll them back if something went wrong. With tools like the staging area and the ability to stage only parts of a file, Git makes it easy to create very granular commits.

COMMIT OFTEN

Committing often keeps your commits small and, again, helps you commit only related changes. Moreover, it allows you to share your code more frequently with others. That way it‘s easier for everyone to integrate changes regularly and avoid having merge conflicts. Having few large commits and sharing them rarely, in contrast, makes it hard to solve conflicts.

DON‘T COMMIT HALF-DONE WORK

You should only commit code when it‘s completed. This doesn‘t mean you have to complete a whole, large feature before committing. Quite the contrary: split the feature‘s implementation into logical chunks and remember to commit early and often. But don‘t commit just to have something in the repository before leaving the office at the end of the day. If you‘re tempted to commit just because you need a clean working copy (to check out a branch, pull in changes, etc.) consider using Git‘s Stash feature instead.

TEST CODE BEFORE YOU COMMIT

Resist the temptation to commit some-thing that you «think» is completed. Test it thoroughly to make sure it really is completed and has no side effects (as far as one can tell). While committing halfbaked things in your local repository only requires you to forgive yourself, having your code tested is even more important when it comes to pushing/sharing your code with others.

WRITE GOOD COMMIT MESSAGES

Begin your message with a short summary of your changes (up to 50 characters as a gui-deline). Separate it from the following body by including a blank line. The body of your message should provide detailed answers to the following questions:› What was the motivation for the change?› How does it differ from the previous implementation?

VERSION CONTROL IS NOT A BACKUP SYSTEM

Having your files backed up on a remote server is a nice side effect of having a version control system. But you should not use your VCS like it was a backup system. When doing version control, you should pay attention to committing semantically (see «related chan-ges») - you shouldn‘t just cram in files.

USE BRANCHES

Branching is one of Git‘s most powerful features - and this is not by accident: quick and easy branching was a central requirement from day one. Branches are the perfect tool to help you avoid mixing up different lines of development. You should use branches extensively in your development workflows: for new features, bug fixes, ideas…

AGREE ON A WORKFLOW

Git lets you pick from a lot of different work-flows: long-running branches, topic branches, merge or rebase, git-flow… Which one you choose depends on a couple of factors: your project, your overall development and deployment workflows and (maybe most importantly) on your and your teammates‘ personal preferences. However you choose to work, just make sure to agree on a common workflow that everyone follows.

HELP & DOCUMENTATION

Get help on the command line

git help <command>

FREE ONLINE RESOURCES

https://www.git-scm.com/docshttp://rogerdudler.github.io/git-guide/index.htmlhttps://www.git-tower.com/learn/git/ebook/en/command-line/introduction