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 <file> to the next commit 在< file >中添加一些更改到下一次提交

    • $ git add -p <file>

  • Commit all local changes in tracked files 提交跟踪文件中的所有本地更改

    • $ git commit -a

  • Commit previously staged changes 提交以前上演的更改

    • $ git commit

  • Change the last commit [Don‘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 <file> 谁更改了<file>中的内容和时间

    • $ git blame <file>

BRANCHES & TAGS 分支标签

  • List all existing branches 列出所有现有分支机构

    • $ git branch -av

  • Switch HEAD branch 切换HEAD分支

    • $ git checkout <branch>

  • Create a new branch based on your current HEAD 根据您当前的HEAD创建一个新分支

    • $ git branch <new-branch>

  • Create a new tracking branch based on a remote branch 基于远程分支创建新的跟踪分支

    • $ git checkout --track <remote/bran-ch>

  • Delete a local branch 删除本地分支

    • $ git branch -d <branch>

  • Mark the current commit with a tag 使用标记标记当前提交

    • $ git tag <tag-name>

BRANCHES & TAGS

  • List all currently configured remotes 列出所有当前配置的遥控器

    • $ git remote -v

  • Show information about a remote 显示有关遥控器的信息

    • $ git remote show <remote>

  • Add new remote repository, named <remote> 添加名为<remote>的新远程存储库

    • $ git remote add <shortname> <url>

  • Download all changes from <remote>, but don’t integrate into HEAD 从< remote>下载所有更改，但不要集成到HEAD中

    • $ git fetch <remote>

  • Download changes and directly merge/integrate into HEAD 下载更改并直接合并集成到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

BRANCHES & TAGS

  • Merge <branch> into your current HEAD 将< branch>合并到当前的HEAD中

    • $ git merge <branch>

  • Rebase your current HEAD onto <branch> Don‘t rebase published commits! 将您当前的HEAD重新定位到<branch>不要重新发布已发布的提交！

    • $ 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 将HEAD指针重置为先前的提交…并放弃此后的所有更改

    • $ git reset --hard <commit>

  • …and preserve all changes as unstaged changes …并将所有更改保留为未分级更改

    • $ git reset <commit>

  • …and preserve uncommitted local changes …并保留未提交的本地更改

    • $ git reset --keep <commit>

  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 de-velopers to understand the changes and roll them back if something went wrong.
  提交应该是相关更改的包装器。例如，修复两个不同的错误应该产生两个单独的提交。小的提交使其他开发人员更容易理解变化，并在出现问题时将其回滚。
  With tools like the staging area and the abi-lity to stage only parts of a file, Git makes it easy to create very granular commits.
  使用暂存区域和abi-lity等工具只能部署文件的一部分，Git可以轻松创建非常精细的提交。

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.
  您应该只在代码完成时提交代码。这并不意味着您必须在提交之前完成整个大型功能。恰恰相反：将功能的实现拆分为逻辑块，并记住提前和经常提交。但是，在一天结束离开办公室之前，不要仅仅在存储库中提供一些东西。如果您因为需要干净的工作副本（检查分支，引入更改等）而想要提交，请考虑使用Git的“Stash”功能。

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 half-baked 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:
  以您的更改的简短摘要开始您的消息（最多50个字符作为gui-deline）。通过包含空行将其与以下主体分开。您的信息正文应提供以下问题的详细答案：
  * What was the motivation for the change?
  改变的动机是什么？
  * How does it differ from the previousimplementation?
  它与以前的实现有何不同？
  Use the imperative, present tense («change», not «changed» or «changes») to be consistent with generated messages from commands like git merge.
  使用命令式，现在时（“更改”，而不是“更改”或“更改”）与来自git merge等命令的生成消息一致。

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.
  在远程服务器上备份文件是拥有版本控制系统的一个很好的副作用。但是你不应该使用你的VCS，就像它是一个备份系统。在进行版本控制时，你应该注意语义上的提交（参见“相关的chan-ges”） - 你不应该只是填入文件。

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…
  分支是Git最强大的功能之一 - 这不是偶然的：从第一天开始，快速简便的分支是一个核心要求。分支机构是帮助您避免混淆不同开发线的完美工具。您应该在开发工作流程中广泛使用分支：新功能，错误修复，想法……

AGREE ON A WORKFLOW 商定工作流程

  Git lets you pick from a lot of different work-flows: long-running branches, topic bran-ches, 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.
  Git允许您从许多不同的工作流程中选择：长期运行的分支，主题分支，合并或变基，git-flow ……您选择哪一个取决于几个因素：您的项目，整体开发和部署工作流程和（可能最重要的）你和​​你的队友的个人偏好。无论您选择工作，只需确保就每个人都遵循的共同工作流程达成一致。

HELP & DOCUMENTATION 帮助和文档

  • Get help on the command line 在命令行上获取帮助
    • $ git help <command>

FREE ONLINE RESOURCES 免费在线资源

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