git中一些有意思的命令(待整理)

一、git基本配置

1、配置全局的用户名和邮箱

git config --global user.name "username"

git config --global user.email "email"

2、查看全局的用户名和邮箱

git config --global user.name
git config --global user.email 

3、将color.ui设置为auto 可以让命令的输出拥有更高的可读性。

git config --global color.ui auto

4、运行下面的命令创建SSH Key

5、git init本地初始化一个仓库，git clone 远程仓库地址：克隆一个仓库的代码到本地。

6、git status查看当前本地仓库的一个状态。

文件未添加到暂存区。

未提交到本地仓库。

7、通过git add命令将文件加入暂存区，再通过git commit命令提交到本地git仓库。添加成功后，可以通过git log命令查看提交日志。

在Index数据结构中记录文件提交之前的状态。

git commit -m '提交注释'

刚才我们只简洁地记述了一行提交信息，如果想要记述得更加详细，请不加– m，直接执行git commit命令。执行后编辑器就会启动，并显示如下结果

在编辑器中记述提交信息的格式如下。
·第一行:用一行文字简述提交的更改内容
·第二行:空行
·第三行以后:记述更改的原因和详细内容
只要按照上面的格式输入，今后便可以通过确认日志的命令或工具看到这些记录。在以#(井号）标为注释的Changes to be committed（要提交的更改）栏中，可以查看本次提交中包含的文件。将提交信息按格式记述完毕后，请保存并关闭编辑器，以#(井号）标为注释的行不必删除。随后，刚才记述的提交信息就会被提交。

只显示提交信息的第一行
如果只想让程序显示第一行简述信息，可以在 git log命令后加上**–pretty=short**。这样一来开发人员就能够更轻松地把握多个提交。

只要在 git log命令后加上目录名，便会只显示该目录下的日志。如果加的是文件名，就会只显示与该文件相关的日志。

如果想查看提交所带来的改动，可以加上– p参数，文件的前后差别就会显示在提交信息之后。

git log -p 

8、git push 将本地仓库的代码推送到远程仓库。

二、常用命令

1、diff

diff 命令算是很常用的，我们经常在做代码改动，但是已经是好几天前的代码，具体做了哪些改动都忘记了，在提交之前需要确认下，这个时候就可以用diff来查看你到底做了什么改动。

需要注意的是，在直接输入 git diff 只能比较当前文件和缓存区文件差异，什么是缓存区？就是你还没有执行 git add 的文件。
当然也可以像下面这样使用：

git diff <$id1> <$id2>          # 比较两次提交之间的差异
git diff <branch1>..<branch2>   # 在两个分支之间比较 
git diff --staged               # 比较暂存区和版本库差异

如果现在执行git diff命令，由于工作树和暂存区的状态并无差别，结果什么都不会显示。要查看与最新提交的差别，请执行以下命令。

git diff HEAD

养成这样一个好习惯:在执行 git commit命令之前先执行git diff HEAD命令，查看本次提交与上次提交之间有什么差别，等确认完毕后再进行提交。这里的HEAD是指向当前分支中最新一次提交的指针。然后使用git log查看一下提交的日志，确认提交成功。

2、branch

git branch命令可以将分支名列表显示，同时可以确认当前所在分支。

3、checkout

checkout 一般用作切换分支使用，比如切换到 develop 分支，可以执行：

git checkout develop

但是 checkout 不只用作切换分支，他可以用来切换 tag，切换到某次 commit，如：

git checkout v1.0
git checkout ffd9f2dd68f1eb21d36cee50dbdd504e95d9c8f7

后面的一长串是commit_id，是每次commit的SHA1值，可以根据 git log 得到。除了有“切换”的意思，checkout 还有一个撤销的作用，举个例子，假设我们在一个分支开发一个小功能，刚写完一半，这时候需求变了，而且是大变化，之前写的代码完全用不了了，好在你刚写，甚至都没有 git add 进暂存区，这个时候很简单的一个操作就直接把原文件还原：

git checkout a.md

这里稍微提下，checkout 命令只能撤销还没有 add 进暂存区的文件。

创建分支

git checkout -b 新分支名称

删除分支

# 删除分支
git checkout -d 分支名
# 强制删除分支
git checkout -D 分支名
# 退回上一个分支
git checkout -

4、merge

合并分支

git merge --no-ff feature-A

这里的**–no-ff** 的作用是禁止快进式合并，将需要合并进来的分支当作是一次提交。

以图表的形式来查看分支的情况。

git log --graph

git log --graph命令可以用图表形式输出提交日志，非常直观，请大家务必记住。

5、reset

更改提交的操作
回溯历史的版本

git reset 
# 回退到上一个commit之前的状态
git reset --soft HEAD^

要让仓库的HEAD、暂存区、当前工作树回溯到指定状态，需要用到git reset --hard命令。只要提供目标时间点的哈希值，就可以完全恢复至该时间点的状态。

6、reflog

git log命令只能查看以当前状态为终点的历史日志。在日志中找出回溯历史之前的哈希值，通过 git reset --hard命令恢复到回溯历史前的状态。所以这里要使用git reflog命令，查看当前仓库的操作日志。首先执行git reflog命令，查看当前仓库执行过的操作的日志。

在日志中，我们可以看到commit、checkout、reset、merge等Git命令的执行记录。只要不进行Git的GC(Garbage Collection，垃圾回收)，就可以通过日志随意调取近期的历史状态，就像给时间机器指定一个时间点，在过去未来中自由穿梭一般。即便开发者错误执行了Git 操作，基本也都可以利用git reflog命令恢复到原先的状态，所以请各位读者务必牢记本部分。

7、消除冲突

这里发生了冲突

查看冲突文件

======= 以上旳部分是当前HEAD的内容，以下的部分是要合并的fix-B分支中的内容。我们在编辑器中将其改成想要的样子。

解决之后，再试用commit提交，这里推荐使用

# 修改提交信息
git commit --amend

8、git rebase -i

在合并特性分支之前，如果发现已提交的内容中有些许拼写错误（typo ）等，不妨提交一个修改，然后将这个修改包含到前一个提交之中，压缩成一个历史记录。这是个会经常用到的技巧。
当对于某些小小的变更就没必要先执行git add 命令再执行git commit 命令了，我们可以直接使用git commit -am 命令来一次完成这两步的一个操作。实际上，我们并不希望在历史记录中看到这类的提交，因为健全的历史记录并不需要它们，如果能在最初的提交之前就发现并修正这些错误，也就不会有这一类的提交合并了。因此，我们来修改 ** 提交历史 **，将本次修正的内容与之前一次的提交合并在一起，然后再历史记录中合并为一次完整的提交。

使用

git rebase -i HEAD~2

选定当前分支中包含HEAD（最新提交）在内的两个最新历史记录为对象，并在编辑器中打开：

我们将6fba227的Fix typo的历史记录压缩到7a31291的Add feature-C里。按照下图所示，将6fba227左侧的pick部分删除，改写为fixup。

保存编辑器里的内容，关闭编辑器，

系统显示rebase 成功，也就是说这两个提交已经合并成了一个新的提交。

9、git remote add 将远程仓库与本地仓库建立连接

git remote add origin URL

按照上述格式执行之后，git会自动将这个URL上的远程仓库的名称设置为origin（标识符）。

10、git push 将代码推送到远程仓库

推送至master分支

git push -u origin master

像这样执行 git push命令，当前分支的内容就会被推送给远程仓库 origin的 master分支。-u参数可以在推送的同时，将origin仓库的master分支设置为本地仓库当前分支的upstream(上游）。添加了这个参数，将来运行 git pull命令从远程仓库获取内容时，本地仓库的这个分支就可以直接从origin的master分支获取内容，省去了另外添加参数的麻烦。
推送至master以外的分支
除了master分支之外，远程仓库也可以创建其他分支。举个例子，我们在本地仓库中创建feature-D分支，并将它以同名形式push至远程仓库。

现在，在远程仓库的GitHub页面就可以查看到feature-D分支了。

11、从远程仓库中拉取代码的方式

第一次使用git clone URL 拉取远程仓库的代码，后面使用git pull --rebase 拉起远程仓库中的代码。
执行 git clone命令后我们会默认处于master分支下，同时系统会自动将origin设置成该远程仓库的标识符。也就是说，当前本地仓库的master分支与GitHub端远程仓库(origin)的 master分支在内容上是完全相同的。
我们用git branch -a命令查看当前分支的相关信息。添加–a参数可以同时显示本地仓库和远程仓库的分支信息。结果中显示了remotes/origin/feature-D，证明我们的远程仓库中已经有了feature-D分支

获取远程的feature-D分支
我们试着将feature-D分支获取至本地仓库。

-b参数的后面是本地仓库中新建分支的名称。为了便于理解，我们仍将其命名为feature-D，让它与远程仓库的对应分支保持同名。新建分支名称后面是获取来源的分支名称。例子中指定了origin/feature-D，就是说以名为 origin的仓库（这里指GitHub端的仓库）的feature-D分支为来源，在本地仓库中创建feature-D分支。

12、git pull 获取最新的远程仓库分支

现在我们放下刚刚操作的目录，回到原先的那个目录下。这边的本地仓库中只创建了feature-D分支，并没有在feature-D分支中进行任何提交。然而远程仓库的feature-D分支中已经有了我们刚刚推送的提交。这时我们就可以使用git pull命令，将本地的feature-D分支更新到最新状态。当前分支为feature-D分支。

git 进阶推荐

3、stash

3.1、git stash

把当前分支所有没有 commit 的代码先暂存起来，这个时候你再执行 git status 你会发现当前分支很干净，几乎看不到任何改动，你的代码改动也看不见了，但其实是暂存起来了。

3.2、git stash list

可以查看你git stash 了几次，就保存下来几条响应的记录。

3.3、git stash apply

你会发现你之前的代码全部又回来了，就好像一切都没发生过一样，紧接着你最好需要把暂存区的这次 stash 记录删除，防止影响到下一次的git stash的使用。

3.4、git stash drop

就把最近一条的 stash 记录删除。

3.5、git stash pop

代替 apply 命令，pop 跟 apply 的唯一区别就是 pop 不但会帮你把代码还原，还自动帮你把这条 stash 记录删除，省的自己再 drop 一次。如果代码发现了冲突，只能先在这个步骤先解决冲突，才能commit。
不过结束之后，通常还是要使用git stash list 来查看是否删除了上一个创建的stash。

3.6、git stash clear

就是清空所有暂存区的记录，drop 是只删除一条，当然后面可以跟 stash_id 参数来删除指定的某条记录，不跟参数就是删除最近的，而 clear 是清空。

4、merge & rebase

merge 分支是合并的意思，我们在一个 featureA 分支开发完了一个功能，这个时候需要合并到主分支 master 上去，我们只需要进行如下操作：

git checkout master
git merge featureA

其实 rebase 命令也是合并的意思，上面的需求我们一样可以如下操作：

git checkout master

git rebase featureA

rebase 跟 merge 的区别你们可以理解成有两个书架，你需要把两个书架的书整理到一起去，第一种做法是 merge ，比较粗鲁暴力，就直接腾出一块地方把另一个书架的书全部放进去，虽然暴力，但是这种做法你可以知道哪些书是来自另一个书架的；第二种做法就是 rebase ，他会把两个书架的书先进行比较，按照购书的时间来给他重新排序，然后重新放置好，这样做的好处就是合并之后的书架看起来很有逻辑，但是你很难清晰的知道哪些书来自哪个书架。

5、解决冲突（重要）

假设这样一个场景，A和B两位同学各自开了两个分支来开发不同的功能，大部分情况下都会尽量互不干扰的，但是有一个需求A需要改动一个基础库中的一个类的方法，不巧B这个时候由于业务需要也改动了基础库的这个方法，因为这种情况比较特殊，A和B都认为不会对别人造成影响，等两人各自把功能做完了，需要合并的到主分支 master 的时候，我们假设先合并A的分支，这个时候没问题的，之后再继续合并B的分支，这个时候想想也知道会有冲突了，因为A和B两个人同时更改了同一个地方，Git 本身他没法判断你们两个谁更改的对，但是这个时候他会智能的提示有 conflicts ，需要手动解决这个冲突之后再重新进行一次 commit 提交。我随便在项目搞了一个冲突做下示例：

以上截图里就是冲突的示例，冲突的地方由 ==== 分出了上下两个部分，上部分一个有 HEAD 的字样代表是我当前所在分支的代码，下半部分是一个叫 baidu_activity 分支的代码，可以看到 HEAD 对 gradle 插件进行了升级，同时新增了一个插件，所以我们很容易判断哪些代码该保留，哪些代码该删除，我们只需要移除掉那些老旧代码，而且同时也要把那些 <<< HEAD、==== 以及 >>>>>>baidu_activity 这些标记符号也一并删除，最后进行一次 commit 就ok了。

我们在开发的过程中一般都会约定尽量大家写的代码不要彼此影响，以减少出现冲突的可能，但是冲突总归无法避免的，我们需要了解并掌握解决冲突的方法。

参考链接：
https://zhuanlan.zhihu.com/p/21367056?utm_source=wechat_session&utm_medium=social&utm_oi=986346114072772608