Git 命令手册 分类明确易记忆

## **本文目录结构：**

	创建仓库 
	本地改变  
	提交历史 
	分支  &&  标签 
	更新  &&  发布 
	合并  &&  变基  
	撤销 
	相关提醒

创建仓库

克隆现有仓库

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

创建一个新的本地仓库

$ git init

本地改变

工作目录下已改变的文件

$ git status

被跟踪文件的改变

$ git diff

添加所有当前改变到下一次提交

$ git add .

添加file中的某些改变到下一次提交

$ git add -p

提交所有本地改变到被跟踪文件

$ git commit -a

提交暂存区中的文件

$ git commit

改变上一次提交

不要修补已发布的提交

$ git commit --amend

提交历史

显示所有提交，从最新到最旧

$ git log

显示特定文件随时间的变化

$ git log -p

谁更改了中的内容和时间

$ git blame

分支 && 标签

罗列所有现有分支

$ git branch -av

切换到当前分支为branch分支

$ git checkout

创建一个新分支作为当前分支

$ git branch

基于远程分支创建一个新的跟踪分支

$ git checkout --track <remote/branch>

删除本地分支

$ git branch -d

用标签来标记当前提交

$ git tag

更新 && 发布

罗列所有当前配置的远程仓库

$ git remote -v

显示远程仓库的信息

$ git remote show

添加新的远程方内置命名为remote

$ git remote add

从远程仓库拉取改变，但不合并到当前分支

$ git fetch

从远程仓库拉取改变，并合并到当前分支

$ git pull

发布本地变化到远程仓库

$ git push

删除远程仓库的分支

$ git branch -dr <remote/branch>

发布标签

$ git push --tags

合并 && 变基

合并branch到当前分支

$ git merge

合并当前分支到branch（即变基），不要变基已发布分支

$ git rebase

停止变基

$ git rebase --abort

解决冲突后继续变基

$ git rebase --continue

使用配置的合并工具解决冲突

$ git mergetool

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

$ git add

$ git rm

撤销

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

$ git reset --hard HEAD

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

$ git checkout HEAD

还原提交（通过产生具有相反更改的新提交）

$ git revert

重置为上一次提交，并放弃上次提交之后工作目录下所有更改

$ git reset --hard

保存所有更爱为未添加到暂存区的更改

$ git reset

保留未提交的更改

$ git reset --keep

相关提醒

COMMIT RELATED CHANGES

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

COMMIT OFTEN

提交通常会使您的提交变小，并且再次帮助您仅提交相关的更改。而且，它使您可以更频繁地与他人共享代码。这样，每个人都可以更轻松地定期集成更改并避免合并冲突。相比之下，大型提交很少且很少共享，因此很难解决冲突。

DON‘T COMMIT HALF-DONE WORK

您只应在代码完成后提交代码。这并不意味着您在提交之前必须先完成一个完整的大型功能。恰恰相反：将功能的实现分成逻辑块，并记住提早并经常提交。但是，不要只想在一天结束前离开办公室就在仓库中存放一些东西。如果您只是因为需要干净的工作副本（签出分支，引入更改等）而打算提交，请考虑改用Git的“隐藏”功能。

TEST CODE BEFORE YOU COMMIT

抵制诱惑，使您“认为”事情完成。对其进行彻底的测试，以确保它确实完成并且没有副作用（据人们所知）。虽然只需要您原谅自己在本地存储库中半熟的事情，但在与他人推送/共享代码方面，测试代码就显得尤为重要

WRITE GOOD COMMIT MESSAGES

首先以简短的更改摘要（最多50个字符为准则）开始您的消息。通过包含空白行将其与后续正文分开。您的邮件正文应提供以下问题的详细答案：›进行更改的动机是什么？ ›与以前的实现有何不同？使用命令式现在时态（“ change”，而不是“ changed”或“ changes”）与git merge等命令生成的消息保持一致。

VERSION CONTROL IS NOT A BACKUP SYSTEM

将文件备份到远程服务器上是拥有版本控制系统的一个很好的副作用。但是，您不应该像使用备份系统那样使用VCS。在进行版本控制时，您应该注意语义上的提交（请参阅“相关更改”）-您不应该只是在文件中塞入。

USE BRANCHES

分支是Git最强大的功能之一-这并不是偶然的：从一开始，快速便捷的分支就成为了中心需求。分支是完美的工具，可帮助您避免混淆不同的开发路线。您应该在开发工作流程中广泛使用分支：有关新功能，错误修复，想法…

AGREE ON A WORKFLOW Git

Git允许您从许多不同的工作流程中进行选择：长期运行的分支，主题分支，合并或重新设置，git-flow…您选择哪一个取决于以下两个因素：项目，整体开发和部署工作流程以及（也许最重要的是），以了解您和您的队友的个人喜好。无论您选择工作，只要确保在每个人都遵循的通用工作流程上达成一致即可。

HELP & DOCUMENTATION

Get help on the command line

$ git help