git文档

git基本指令

git init

这个时候用到了第一个命令，代表初始化 git 仓库，输入 git init 之后会提示：

可以看到初始化成了，至此 test 目录已经是一个 git 仓库了。

git status

紧接着我们输入 git status 命令，会有如下提示：

默认就直接在 master 分支，关于分支的概念后面会提，这时最主要的是提示 a.md 文件 ，Untracked files ，就是说 a.md 这个文件还没有被跟踪，还没有提交在 git 仓库里呢，而且提 示你可以使用 git add 去操作你想要提交的文件。

git status 这个命令顾名思义就是查看状态，这个命令可以算是使用最频繁的一个命令了，建 议大家没事就输入下这个命令，来查看你当前 git 仓库的一些状态。

git add

上面提示 a.md 文件还没有提交到 git 仓库里，这个时候我们可以随便编辑下 a.md 文件，然 后输入 git add a.md ，然后再输入 git status :

此时提示以下文件 Changes to be committed ， 意思就是 a.md 文件等待被提交，当然你可以使用 git rm --cached * 这个命令去移除这个缓存。

git commit

接着我们输入 git commit -m 'first commit' ，这个命令什么意思呢？ commit 是提交的意思，- m 代表是提交信息，执行了以上命令代表我们已经正式进行了第一次提交。 这个时候再输入 git status ，会提示 nothing to commit。

git branch

执行 git init 初始化git仓库之后会默认生成一个主分支 master ，也是你所在的默认分支，也基 本是实际开发正式环境下的分支，一般情况下 master 分支不会轻易直接在上面操作的，你们可以输入 git branch 查看下当前分支情况：

如果我们想在此基础上新建一个分支呢，很简单，执行 git branch a 就新建了一个名字叫 a 的分支，这时候分支 a 跟分支 master 是一模一样的内容，我们再输入 git branch 查看的当前分支情况：

但是可以看到 master 分支前有个 * 号，即虽然新建了一个 a 的分支，但是当前所在的分支还是在 master 上，如果我们想在 a 分支上进行开发，首先要先切换到 a 分支上才行，所以下一步要切换分支

git checkout a 

执行这个命令，然后再输入 git branch 查看下分支情况：

可以看到当前我们在的分支已经是a了，这个时候 A 同学就可以尽情的在他新建的a分支去进行代码改动了。

那有人就说了，我要先新建再切换，未免有点麻烦，有没有一步到位的，聪明：

git checkout -b a

git merge

A同学在a分支代码写的不亦乐乎，终于他的功能完工了，并且测试也都ok了，准备要上线了，这个时候就需要把他的代码合并到主分支master上来，然后发布。git merge 就是合并分支用到的命令，针对这个情况，需要先做两步，第一步是切换到 master 分支，如果你已经在了就不用切换了，第二步执行 git merge a ，意思就是把a分支的代码合并过来，不出意外，这个时候a分支的代码就顺利合并到 master 分支来了。为什么说不出意外呢？因为这个时候可能会有冲突而合并失败，留个包袱，这个到后面进阶的时候再讲。

git branch -d

有新建分支，那肯定有删除分支，假如这个分支新建错了，或者a分支的代码已经顺利合并到master分支来了，那么a分支没用了，需要删除，这个时候执行 git branch -d a 就可以把a分支删除了。

git branch -D

有些时候可能会删除失败，比如如果a分支的代码还没有合并到master，你执行 git branch -d a 是删除不了的，它会智能的提示你a分支还有未合并的代码，但是如果你非要删除，那就执 行 git branch -D a 就可以强制删除a分支。

git tag

我们在客户端开发的时候经常有版本的概念，比如v1.0、v1.1之类的，不同的版本肯定对应不同的代码，所以我一般要给我们的代码加上标签，这样假设v1.1版本出了一个新bug，但是又不晓得v1.0是不是有这个bug，有了标签就可以顺利切换到v1.0的代码，重新打个包测试了。

所以如果想要新建一个标签很简单，比如 git tag v1.0 就代表我在当前代码状态下新建了一个v1.0的标签，输入 git tag 可以查看历史 tag 记录。

想要切换到某个tag怎么办？也很简单，执行 git checkout v1.0 ，这样就顺利的切换到 v1.0 tag的代码状态了。

git进阶

checkout

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

git checkout develop

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

git checkout v1.0 
git checkout ffd9f2dd68f1eb21d36cee50dbdd504e95d9c8f7 # 后面的一长串是commit_id，是每次com mit的SHA1值，可以根据 git log 看到。

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

git checkout a.md

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

stash

设想一个场景，假设我们正在一个新的分支做新的功能，这个时候突然有一个紧急的bug需要修复，而且修复完之后需要立即发布。当然你说我先把刚写的一点代码进行提交不就行了么？这样理论上当然是ok的，但是这会产品垃圾commit，原则上我们每次的commit都要有实际的意义，你的代码只是刚写了一半，还没有什么实际的意义是不建议就这样commit的，那么有没有一种比较好的办法，可以让我暂时切到别的分支，修复完bug再切回来，而且代码也能保留的呢？

这个时候 stash 命令就大有用处了，前提是我们的代码没有进行 commit ，哪怕你执行了 add 也没关系，我们先执行

git stash

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

git stash list

你会发现此时暂存区已经有了一条记录。

这个时候你可以切换会其他分支，赶紧把bug修复好，然后发布。之后一切都解决了，你再切换回来继续做你之前没做完的功能，但是之前的代码怎么还原呢？

git stash apply

你会发现你之前的代码全部又回来了，就好像一切都没发生过一样，紧接着你最好需要把暂存区的这次 stash 记录删除，执行：

git stash drop

就把最近一条的 stash 记录删除了，是不是很方便？其实还有更方便的，你可以使用：

git stash pop

来代替 apply 命令，pop 跟 apply 的唯一区别就是 pop 不但会帮你把代码还原，还自动帮你 把这条 stash 记录删除，省的自己再 drop 一次了，为了验证你可以紧接着执行 git stash， list 命令来确认是不是已经没有记录了。

最后还有一个命令介绍下：

git stash clear

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

merge & rebase

merge上面已经介绍过，这里就不在赘述了，rebase使用方式与merge相同，但也有区别

rebase 跟 merge 的区别你们可以理解成有两个书架，你需要把两个书架的书整理到一起去，第一种做法是 merge ，比较粗鲁暴力，就直接腾出一块地方把另一个书架的书全部放进去，虽然暴力，但是这种做法你可以知道哪些书是来自另一个书架的；第二种做法就是

rebase ，他会把两个书架的书先进行比较，按照购书的时间来给他重新排序，然后重新放置好，这样做的好处就是合并之后的书架看起来很有逻辑，但是你很难清晰的知道哪些书来自哪个书架的。

只能说各有好处的，不同的团队根据不同的需要以及不同的习惯来选择就好。

解决冲突

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

以上截图里就是冲突的示例，冲突的地方由 * 分出了上下两个部分，上部分一个叫 HEAD 的字样代表是我当前所在分支的代码，下半部分是一个叫 baidu_activity 分支的代码，可以看到 HEAD 对 gradle 插件进行了升级，同时新增了一个插件，所以我们很容易判断哪些代码该保留，哪些代码该删除，我们只需要移除掉那些老旧代码，而且同时也要把那些 <<< HEAD、*** 以及 >>>>>>baidu_activity 这些标记符号也一并删除，最后进行一次commit 就ok了。我们在开发的过程中一般都会约定尽量大家写的代码不要彼此影响，以减少出现冲突的可能，但是冲突总归无法避免的，我们需要了解并掌握解决冲突的方法。

git分支

分支的常用操作

通常我们默认都会有一个主分支叫 master ，下面我们先来看下关于分支的一些基本操作：

• 新建一个叫 develop 的分支

git branch develop

这里稍微提醒下大家，新建分支的命令是基于当前所在分支的基础上进行的，即以上是基于mater 分支新建了一个叫做 develop 的分支，此时 develop 分支跟 master 分支的内容完全一样。如果你有 A、B、C三个分支，三个分支是三位同学的，各分支内容不一样，如果你当前是在 B 分支，如果执行新建分支命令，则新建的分支内容跟 B 分支是一样的，同理如果当前所在是 C 分支，那就是基于 C 分支基础上新建的分支。

• 切换到 develop 分支

git checkout develop

• 如果把以上两步合并，即新建并且自动切换到 develop 分支：

git checkout -b develop

• 把 develop 分支推送到远程仓库

git push origin develop

• 如果你远程的分支想取名叫 develop2 ，那执行以下代码：

git push origin develop:develop2

但是强烈不建议这样，这会导致很混乱，很难管理，所以建议本地分支跟远程分支名要保持一致。

• 查看本地分支列表

git branch 

• 查看远程分支列表

git branch -r 

• 删除本地分支

git branch -d develop 

git branch -D develop (强制删除) 

• 删除远程分支

git push origin :develop 

• 如果远程分支有个 develop ，而本地没有，你想把远程的 develop 分支迁到本地：

git checkout develop origin/develop 

• 同样的把远程分支迁到本地顺便切换到该分支：

git checkout -b develop origin/develop 

基本的团队协作流程

Git Flow

准确的说 Git Flow 是一种比较成熟的分支管理流程，我们先看一张图能清晰的描述他整个的工作流程：

第一次看上面那个图是不是一脸懵逼？跟我当时一样，不急，我来用简单的话给你们解释下。

一般开发来说，大部分情况下都会拥有两个分支 master 和 develop，他们的职责分别是：

• master：永远处在即将发布(production-ready)状态
• develop：最新的开发状态

确切的说 master、develop 分支大部分情况下都会保持一致，只有在上线前的测试阶段develop 比 master 的代码要多，一旦测试没问题，准备发布了，这时候会将 develop 合并到master 上。

但是我们发布之后又会进行下一版本的功能开发，开发中间可能又会遇到需要紧急修复 bug，一个功能开发完成之后突然需求变动了等情况，所以 Git Flow 除了以上 master 和 develop两个主要分支以外，还提出了以下三个辅助分支：

• feature: 开发新功能的分支, 基于 develop, 完成后 merge 回 develop
• release: 准备要发布版本的分支, 用来修复 bug，基于 develop，完成后 merge 回develop 和 master
• hotfix: 修复 master 上的问题, 等不及 release 版本就必须马上上线. 基于 master, 完成后merge 回 master 和 develop

什么意思呢？

举个例子，假设我们已经有 master 和 develop 两个分支了，这个时候我们准备做一个功能A，第一步我们要做的，就是基于 develop 分支新建个分支：

git branch feature/A 

看到了吧，其实就是一个规范，规定了所有开发的功能分支都以 feature 为前缀。

但是这个时候做着做着发现线上有一个紧急的 bug 需要修复，那赶紧停下手头的工作，立刻切换到 master 分支，然后再此基础上新建一个分支：

git branch hotfix/B

代表新建了一个紧急修复分支，修复完成之后直接合并到 develop 和 master ，然后发布。然后再切回我们的 feature/A 分支继续着我们的开发，如果开发完了，那么合并回 develop 分支，然后在 develop 分支属于测试环境，跟后端对接并且测试的差不多了，感觉可以发布到正式环境了，这个时候再新建一个 release 分支：

git branch release/1.0

这个时候所有的 api、数据等都是正式环境，然后在这个分支上进行最后的测试，发现 bug 直接进行修改，直到测试 ok 达到了发布的标准，最后把该分支合并到 develop 和 master 然后进行发布。

以上就是 Git Flow 的概念与大概流程，看起来很复杂，但是对于人数比较多的团队协作现实开发中确实会遇到这么复杂的情况，是目前很流行的一套分支管理流程，但是有人会问每次都要各种操作，合并来合并去，有点麻烦，哈哈，这点 Git Flow 早就想到了，为此还专门推出了一个 Git Flow 的工具，并且是开源的：

GitHub 开源地址：https://github.com/nvie/gitflow

简单点来说，就是这个工具帮我们省下了很多步骤，比如我们当前处于 master 分支，如果想要开发一个新的功能，第一步切换到 develop 分支，第二步新建一个以 feature 开头的分支名，有了 Git Flow 直接如下操作完成了：

git flow feature start A 

这个分支完成之后，需要合并到 develop 分支，然而直接进行如下操作就行：

git flow feature finish A

如果是 hotfix 或者 release 分支甚至会自动帮你合并到 develop、master 两个分支。

想必大家已经了解了这个工具的具体作用，具体安装与用法我就不多提了，感兴趣的可以看 下一篇博客：

http://stormzhang.com/git/2014/01/29/git-flow/

git commit 详解

我们知道Git有三大区（工作区、暂存区、版本库）以及几个状态（untracked、unstaged、uncommited）

一、简介

Git 保存的不是文件的变化或者差异，而是一系列不同时刻的文件快照。

git reset命令是git中重置命令，即用来撤销某次提交(commit)。首先，我们得了解，git reset可以帮我们重置哪些内容：

1、修改本地仓库中commit对象(快照)

如下图：

此时本地仓库对应的是commit4，git reset 可以让本地仓库对应的指针变为commit3或是commit1等之前的版本，当然，也可以变为commit4之后的某个commit，如commit5。
Git 的分支，其实本质上仅仅是指向提交对象的可变指针。
备注：当使用git reset命令时候，一般会修改本地仓库。

其常用格式如下：

• 用法一：git reset [-q] [] [–] …
• 用法二：git reset [–soft | --mixed | --hard | --merge | --keep ] [-q] [commit]

二、参数

参数说明 (git log和git reflog可查看commitId，commitId是快照的唯一标识)

• –hard commitId 修改本地仓库、暂存区、工作区里面的数据为commitId对应快照的内数据

• –mixed commitId 修改本地仓库、暂存区里面的数据为commitId对应快照里的数据，是git reset默认的参数，–mixed可缺省。 暂存区的数据会被快照中的数据覆盖

这种情况是工作区没有，但暂存区有，所以提示修改未在暂存区（D表示delete）

• –soft commitId 修改本地仓库里面的数据为commitId对应快照的数据。(仅改变指向快照的指针指向)

当git reset 后面的commitId为当前提交的commitId时，即HEAD(可缺省)。那么：

参数说明

• –hard HEAD 修改暂存区、工作区里面的内容为当前快照里的内容。（这个很危险，曾经踩过坑，电脑的文件丢失了很多，也是导致我决心好好学一学git的原因，慎用）
• –mixed HEAD 修改暂存区里面的内容为当前快照里的内容，是git reset默认的参数，因此可缺省。
• –soft HEAD 本地仓库、暂存区、工作区都不改变 |

我们需要注意，使用git reset重置一般是很危险的，会彻底地丢掉历史。因为如果没有记录下重置前的commitId，一般不容易找回，除非分析.git/logs里面的日志，故重置需慎重。

git diff只对已被追踪的文件起作用，即已git add过，在暂存区有的

git commit -a -m只对已被追踪的文件起作用，