现在总结一下今天学的两点内容：
初始化一个Git仓库，使用git init命令。
添加文件到Git仓库，分两步：
第一步，使用命令
git add <file>，注意，可反复多次使用，添加多个文件；第二步，使用命令
git commit，完成。小结
要随时掌握工作区的状态，使用
git status命令。如果
git status告诉你有文件被修改过，用git diff可以查看修改内容。
如果你修改了新的内容，但是没有提交commit，那么git status的时候就会有问题
$ mkdir learngit //创建一个文件夹
$ cd learngit 进入这个文件夹
$ pwd
/c/Users/adminstration/learngit //显示文件夹的路径
$ git init //把这个文件夹当成本地库
Initialized empty Git repository in C:/Users/adminstration/learngit/.git/
$ git add new1.txt //把new1.txt文件add进去
$git rm new1.txt //删除某个文件
$ cd learngit 进入这个文件夹
$ pwd
/c/Users/adminstration/learngit //显示文件夹的路径
$ git init //把这个文件夹当成本地库
Initialized empty Git repository in C:/Users/adminstration/learngit/.git/
$ git add new1.txt //把new1.txt文件add进去
$git rm new1.txt //删除某个文件
$ git commit -m "..." //把add的文件都commit出去 "..." 里面的内容是 注释.相当于每次提交都会有一个备注。
$ cat new1.txt //显示cat的内容
$ git diff new1.txt //这个只能是没有add的文件，显示 没有add的文件，和已经commit的文件的区别
$ git log //显示commit的日志
commit 618d0be8843a3e5f3053ac50b76e64d0ad41131a (HEAD -> master)
Author: q139861200 <373614724@qq.com>
Date: Wed Sep 27 19:55:51 2017 +0800
commit 77773cdcbf09546f77b4a9c52a249a2cdce7aa78
Author: q139861200 <373614724@qq.com>
Date: Wed Sep 27 17:47:55 2017 +0800
changed to be committed
commit 6f12941ed0c25873d46c3ffce0f0ee3c1515a04a
Author: q139861200 <373614724@qq.com>
Date: Wed Sep 27 17:32:53 2017 +0800
my first file committed
commit 618d0be8843a3e5f3053ac50b76e64d0ad41131a (HEAD -> master)
Author: q139861200 <373614724@qq.com>
Date: Wed Sep 27 19:55:51 2017 +0800
Git必须知道当前版本是哪个版本，在Git中，用HEAD表示当前版本，也就是最新的提交3628164...882e1e0（注意我的提交ID和你的肯定不一样），上一个版本就是HEAD^，上上一个版本就是HEAD^^，当然往上100个版本写100个^比较容易数不过来，所以写成HEAD~100。
现在，我们要把当前版本“append GPL”回退到上一个版本“add distributed”，就可以使用git reset命令：
$ git reset --hard HEAD^
HEAD is now at ea34578 add distributedcommit 77773cdcbf09546f77b4a9c52a249a2cdce7aa78
Author: q139861200 <373614724@qq.com>
Date: Wed Sep 27 17:47:55 2017 +0800
changed to be committed
commit 6f12941ed0c25873d46c3ffce0f0ee3c1515a04a
Author: q139861200 <373614724@qq.com>
Date: Wed Sep 27 17:32:53 2017 +0800
my first file committed
现在，我们要把当前版本“append GPL”回退到上一个版本“add distributed”，就可以使用git reset命令：
$ git reset --hard HEAD^
HEAD is now at ea34578 add distributed
$ git reflog //来查找之前的序列号
$ git checkout LICENSE.txt //如果之前已经commit了， 但是你在 工作区里面做了很多修改，那么就用这，把工作区的东西还原跟commit一样。如果有 缓存区，那么就优先还原缓冲区里面
git reset HEAD LICENSE.txt //把暂存区的内容取消，保留工作区的内容
git rm LICENSE.txt //会把你工作区的文件删除，并且会把这个删除的信息发送到 暂存区。如果要还原，先把暂存区的内容清除，用上面的命令。
在用git checkout LICENSE.txt 还原
$ git remote add origin git@github.com:michaelliao/learngit.git //把本地的仓库和网上的关联起来 这里的origin是 远程仓库的名字，这个名字是相对于本地仓库来说的，githu网站上面远程仓库的名字也许并不是这个名字。$ git push origin master //这里面的origin是相对于本地仓库对 关联的远程仓库的名字( 实际的名字是以github网站上面的为准)$ git clone git@github.com:michaelliao/gitskills.git //michaelliao是你的账号，后面gitskills是具体的仓库$ git checkout -b dev
Switched to a new branch 'dev'
git checkout命令加上-b参数表示创建并切换，相当于以下两条命令：
$ git branch dev
$ git checkout dev
Switched to branch 'dev'
然后，用git branch命令查看当前分支：
$ git branch
* dev
master$ git merge dev 把dev的内容合并到当前分支。也就是覆盖当前分支的内容。
修复bug时，我们会通过创建新的bug分支进行修复，然后合并，最后删除；
当手头工作没有完成时，先把工作现场git stash一下，然后去修复bug，修复后，再git stash pop，回到工作现场。
git remote -v
显示远程仓库的详细信息
git remote remove origin //删除这个远程仓库
$ git push origin master
如果要推送其他分支，比如dev，就改成：
$ git push origin dev$ git clone git@github.com:michaelliao/learngit.git //如果github上面的这个仓库里面有分支，那么你clone下来之后是看不到这个分支的。$ git checkout -b dev origin/dev //创建一个dev，和远程的dev关联起来。 这份本地的分支要跟远程的分支同名。$ git push origin dev //origin是远程仓库，dev是远程分支。1
=======
2
>>>>>>> b4f33a1012c1e15cdc63b62f9ac97c17d5b5debe
// HEAD表示你本地有，远程仓库没有的， ======= 下面表示本地没有，远程仓库有的内容
git pull也失败了，原因是没有指定本地dev分支与远程origin/dev分支的链接，根据提示，设置dev和origin/dev的链接：
$ git branch --set-upstream dev origin/dev因此，多人协作的工作模式通常是这样：
首先，可以试图用
git push origin branch-name推送自己的修改；如果推送失败，则因为远程分支比你的本地更新，需要先用
git pull试图合并；如果合并有冲突，则解决冲突，并在本地提交；
没有冲突或者解决掉冲突后，再用
git push origin branch-name推送就能成功！
如果git pull提示“no tracking information”，则说明本地分支和远程分支的链接关系没有创建，用命令git branch --set-upstream branch-name origin/branch-name。
这就是多人协作的工作模式，一旦熟悉了，就非常简单。
小结
查看远程库信息，使用
git remote -v；本地新建的分支如果不推送到远程，对其他人就是不可见的；
从本地推送分支，使用
git push origin branch-name，如果推送失败，先用git pull抓取远程的新提交；在本地创建和远程分支对应的分支，使用
git checkout -b branch-name origin/branch-name，本地和远程分支的名称最好一致；建立本地分支和远程分支的关联，使用
git branch --set-upstream branch-name origin/branch-name；从远程抓取分支，使用
git pull，如果有冲突，要先处理冲突。
本地master只能跟远程master 对应， 分支的内容 上传 也只会跟 远程的分支 来对应起来。不会混着搞
===============================================
另一位博客
1. 用线上版本强制覆盖本地代码
有时候本地调试、debug，本地代码已经改的一团糟了；或者线上功能好使，而本地功能不好使，希望用线上代码强制覆盖本地代码，git命令如下：
git fetch --all //获取线上所有分支的的代码
git reset --hard origin/master //使用远程(origin)master分支的代码覆盖本地代码
- 1
- 2
- 3
注意：此命令与git checkout . 的区别，checkout是放弃本地修改，将代码回退到本地版本库最新版本，reset是放弃本地修改，将本地代码回退到线上最新版本
第一步，我们先新建一个文件夹，在文件夹里新建一个文件（我是用 Linux 命令去新建的，Windows用户可以自己手动新建）
mkdir test （创建文件夹test） cd test （切换到test目录） touch a.md （新建a.md文件）
这里提醒下：在进行任何 Git 操作之前，都要先切换到 Git 仓库目录，也就是先要先切换到项目的文件夹目录下。
这个时候我们先随便操作一个命令，比如 git status ，可以看到如下提示（别纠结颜色之类的，配置与主题不一样而已）：
意思就是当前目录还不是一个 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 log
这个时候我们输入 git log 命令，会看到如下：
git log 命令可以查看所有产生的 commit 记录，所以可以看到已经产生了一条 commit 记录，而提交时候的附带信息叫 ‘first commit’ 。
git add & git commit
看到这里估计很多人会有疑问，我想要提交直接进行 commit 不就行了么，为什么先要再 add 一次呢？首先 git add 是先把改动添加到一个「暂存区」，你可以理解成是一个缓存区域，临时保存你的改动，而 git commit 才是最后真正的提交。这样做的好处就是防止误提交，当然也有办法把这两步合并成一步，不过后面再介绍，建议新手先按部就班的一步步来。
git branch
branch 即分支的意思，分支的概念很重要，尤其是团队协作的时候，假设两个人都在做同一个项目，这个时候分支就是保证两人能协同合作的最大利器了。举个例子，A, B俩人都在做同一个项目，但是不同的模块，这个时候A新建了一个分支叫a， B新建了一个分支叫b，这样A、B做的所有代码改动都各自在各自的分支，互不影响，等到俩人都把各自的模块都做完了，最后再统一把分支合并起来。
执行 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
这个命令的意思就是新建一个a分支，并且自动切换到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 记录。
可以看到我新建了两个标签 v1.0、v1.1。
想要切换到某个tag怎么办？也很简单，执行 git checkout v1.0 ，这样就顺利的切换到 v1.0 tag的代码状态了。
OK，以上全是一些最基本的Git操作，而且全是在本地环境进行操作的，完全没有涉及到远程仓库，下一章节将以远程 GitHub 仓库为例，讲解下本地如何跟远程仓库一起同步协作，另外今天讲的全是最基础最简单的Git操作，一步步来，后续再继续讲解一下Git的高阶以及一些Git的酷炫操作。
另外，考虑到可能会有人嫌我讲解的太基础太慢，毕竟我是针对小白，所以得一步步来，迫不及待的想要提前自己学习的不妨在我公众号 AndroidDeveloper 回复「git」关键字，获取一份我推荐的还不错的 Git 学习资料，不谢，毕竟我这么帅！
1. SSH
你拥有了一个 GitHub 账号之后，就可以自由的 clone 或者下载其他项目，也可以创建自己的项目，但是你没法提交代码。仔细想想也知道，肯定不可能随意就能提交代码的，如果随意可以提交代码，那么 GitHub 上的项目岂不乱了套了，所以提交代码之前一定是需要某种授权的，而 GitHub 上一般都是基于 SSH 授权的。
那么什么是 SSH 呢？ 简单点说，SSH是一种网络协议，用于计算机之间的加密登录。目前是每一台 Linux 电脑的标准配置。而大多数 Git 服务器都会选择使用 SSH 公钥来进行授权，所以想要在 GitHub 提交代码的第一步就是要先添加 SSH key 配置。
2. 生成SSH key
Linux 与 Mac 都是默认安装了 SSH ，而 Windows 系统安装了 Git Bash 应该也是带了 SSH 的。大家可以在终端（win下在 Git Bash 里）输入 ssh 如果出现以下提示证明你本机已经安装 SSH， 否则请搜索自行安装下。
紧接着输入 ssh-keygen -t rsa ，什么意思呢？就是指定 rsa 算法生成密钥，接着连续三个回车键（不需要输入密码），然后就会生成两个文件 id_rsa 和 id_rsa.pub ，而 id_rsa 是密钥，id_rsa.pub 就是公钥。这两文件默认分别在如下目录里生成：
Linux/Mac 系统 在 ~/.ssh 下，win系统在 /c/Documents and Settings/username/.ssh 下，都是隐藏文件，相信你们有办法查看的。
接下来要做的是把 id_rsa.pub 的内容添加到 GitHub 上，这样你本地的 id_rsa 密钥跟 GitHub 上的 id_rsa.pub 公钥进行配对，授权成功才可以提交代码。
3. GitHub 上添加 SSH key
第一步先在 GitHub 上的设置页面，点击最左侧 SSH and GPG keys ：
然后点击右上角的 New SSH key 按钮：
需要做的只是在 Key 那栏把 id_rsa.pub 公钥文件里的内容复制粘贴进去就可以了（上述示例为了安全粘贴的公钥是无效的），Title 那栏不需要填写，点击 Add SSH key 按钮就ok了。
这里提醒下，怎么查看 id_rsa.pub 文件的内容？
Linux/Mac 用户执行以下命令：
cd ~/.ssh
cat id_rsa.pub
Windows用户，设置显示隐藏文件，可以使用 EditPlus 或者 Sublime 打开复制就行了。
SSH key 添加成功之后，输入 ssh -T git@github.com 进行测试，如果出现以下提示证明添加成功了。
4. Push & Pull
在提交代码之前我们先要了解两个命令，也是上次的文章没有介绍的，因为这两个命令需要跟远程仓库配合。
Push ：直译过来就是「推」的意思，什么意思呢？如果你本地代码有更新了，那么就需要把本地代码推到远程仓库，这样本地仓库跟远程仓库就可以保持同步了。
代码示例： git push origin master
意思就是把本地代码推到远程 master 分支。
Pull：直译过来就是「拉」的意思，如果别人提交代码到远程仓库，这个时候你需要把远程仓库的最新代码拉下来，然后保证两端代码的同步。
代码示例： git pull origin master
意思就是把远程最新的代码更新到本地。一般我们在 push 之前都会先 pull ，这样不容易冲突。
5. 提交代码
添加 SSH key 成功之后，我们就有权限向 GitHub 上我们自己的项目提交代码了，而提交代码有两种方法：
Clone自己的项目 我们以我在 GitHub 上创建的 test 项目为例，执行如下命令：
git clone git@github.com:stormzhang/test.git
这样就把 test 项目 clone 到了本地，你可以把 clone 命令理解为高级点的复制，这个时候该项目本身就已经是一个git 仓库了，不需要执行 git init 进行初始化，而且甚至都已经关联好了远程仓库，我们只需要在这个 test 目录下任意修改或者添加文件，然后进行 commit ，之后就可以执行：
git push origin master
进行代码提交，这种是最简单方便的一种方式。
至于怎么获取项目的仓库地址呢？如下图：
关联本地已有项目 如果我们本地已经有一个完整的 git 仓库，并且已经进行了很多次 commit ，这个时候第一种方法就不适合了。
假设我们本地有个 test2 的项目，我们需要的是在 GitHub 上建一个 test 的项目，然后把本地 test2 上的所有代码 commit 记录提交到 GitHub 上的 test 项目。
第一步就是在 GitHub 上建一个 test 项目，这个想必大家都会了，就不用多讲了。
第二步把本地 test2 项目与 GitHub 上的 test 项目进行关联，切换到 test2 目录，执行如下命令：
git remote add origin git@github.com:stormzhang/test.git
什么意思呢？就是添加一个远程仓库，他的地址是 git@github.com:stormzhang/test.git ，而 origin 是给这个项目的远程仓库起的名字，是的，名字你可以随便取，只不过大家公认的只有一个远程仓库时名字就是 origin ，为什么要给远程仓库取名字？因为我们可能一个项目有多个远程仓库？比如 GitHub 一个，比如公司一个，这样的话提交到不同的远程仓库就需要指定不同的仓库名字了。
查看我们当前项目有哪些远程仓库可以执行如下命令：
git remote -v
接下来，我们本地的仓库就可以向远程仓库进行代码提交了：
git push origin master
就是默认向 GitHub 上的 test 目录提交了代码，而这个代码是在 master 分支。当然你可以提交到指定的分支，这个之后的文章再详细讲解。
对了，友情提醒，在提交代码之前先要设置下自己的用户名与邮箱，这些信息会出现在所有的 commit 记录里，执行以下代码就可以设置：
git config —global user.name "stormzhang"
git config —global user.email "stormzhang.dev@gmail.com"
1. 用户名和邮箱
我们知道我们进行的每一次commit都会产生一条log，这条log标记了提交人的姓名与邮箱，以便其他人方便的查看与联系提交人，所以我们在进行提交代码的第一步就是要设置自己的用户名与邮箱。执行以下代码：
git config --global user.name "stormzhang"
git config --global user.email "stormzhang.dev@gmail.com"
以上进行了全局配置，当然有些时候我们的某一个项目想要用特定的邮箱，这个时候只需切换到你的项目，以上代码把 –global 参数去除，再重新执行一遍就ok了。
PS：我们在 GitHub 的每次提交理论上都会在 主页的下面产生一条绿色小方块的记录，如果你确认你提交了，但是没有绿色方块显示，那肯定是你提交代码配置的邮箱跟你 GitHub 上的邮箱不一致，GitHub 上的邮箱可以到 Setting -> Emails里查看。
2. alias
我们知道我们执行的一些Git命令其实操作很频繁的类似有：
git commit
git checkout
git branch
git status
...
这些操作非常频繁，每次都要输入完全是不是有点麻烦，有没有一种简单的缩写输入呢？比如我对应的直接输入以下：
git c
git co
git br
git s
...
是不是很简单快捷啊？这个时候就用到了alias配置了，翻译过来就是别名的意思，输入以下命令就可以直接满足了以上的需求。
git config --global alias.co checkout # 别名
git config --global alias.ci commit
git config --global alias.st status
git config --global alias.br branch
当然以上别名不是固定的，你完全可以根据自己的习惯去定制，除此之外还可以设置组合，比如：
git config --global alias.psm 'push origin master'
git config --global alias.plm 'pull origin master'
之后经常用到的git push origin master 和 git pull origin master 直接就用 git psm 和 git plm 代替了，是不是很方便？
另外这里给大家推荐一个很强大的 alias 命令，我们知道我们输入 git log 查看日志的时候是类似这样的：
告诉大家一个比较屌的命令，输入**git log –graph –pretty=format:’%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset’ –abbrev-commit –date=relative ** 然后日志这样了：
是不是比较清晰，整个分支的走向也很明确，但是每次都要输这么一大串是不是也很烦？这时候你就该想到 alias 啊：
git config --global alias.lg "log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative"
这样以后直接输入 git lg 就行了。
3. 其他配置
当然还有一些其他有用的配置，默认情况下 git 用的编辑器是 vi ，如果不喜欢可以改成其他编辑器，比如我习惯 vim 。
git config --global core.editor "vim" # 设置Editor使用vim
你们如果喜欢其他编辑器可自行搜索配置，前提是本机有安装。
有些人纳闷我的终端怎么有各种颜色，自己却不是这样的，那是因为你们没有开启给 Git 着色，输入如下命令即可：
git config --global color.ui true
还有些其他的配置如：
git config --global core.quotepath false # 设置显示中文文件名
以上基本所有的配置就差不多了，默认这些配置都在 ~/.gitconfig 文件下的，你可以找到这个文件查看自己的配置，也可以输入 git config -l 命令查看。
4. diff
diff命令算是很常用的，使用场景是我们经常在做代码改动，但是有的时候2天前的代码了，做了哪些改动都忘记了，在提交之前需要确认下，这个时候就可以用diff来查看你到底做了哪些改动，举个例子，比如我有一个 a.md 的文件，我现在做了一些改动，然后输入 git diff 就会看到如下：
红色的部分前面有个 - 代表我删除的，绿色的部分前面有个 + 代表我增加的，所以从这里你们很一目了然的知道我到底对这个文件做了哪些改动。
值得一提的是直接输入 git diff 只能比较当前文件和暂存区文件差异，什么是暂存区？就是你还没有执行 git add 的文件。
当然跟暂存区做比较之外，他还可以有其他用法，如比较两次 commit 之间的差异，比较两个分支之间的差异，比较暂存区和版本库之间的差异等，具体用法如下：
git diff <$id1> <$id2> # 比较两次提交之间的差异
git diff <branch1>..<branch2> # 在两个分支之间比较
git diff --staged # 比较暂存区和版本库差异
5. 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 进暂存区的文件。
6. 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 是清空。
7. merge & rebase
我们知道 merge 分支是合并的意思，我们在一个 featureA 分支开发完了一个功能，这个时候需要合并到主分支 master 上去，我们只需要进行如下操作：
git checkout master
git merge featureA
其实 rebase 命令也是合并的意思，上面的需求我们一样可以如下操作：
git checkout master
git rebase featureA
rebase 跟 merge 的区别你们可以理解成有两个书架，你需要把两个书架的书整理到一起去，第一种做法是 merge ，比较粗鲁暴力，就直接腾出一块地方把另一个书架的书全部放进去，虽然暴力，但是这种做法你可以知道哪些书是来自另一个书架的；第二种做法就是 rebase ，他会把两个书架的书先进行比较，按照购书的时间来给他重新排序，然后重新放置好，这样做的好处就是合并之后的书架看起来很有逻辑，但是你很难清晰的知道哪些书来自哪个书架的。
只能说各有好处的，不同的团队根据不同的需要以及不同的习惯来选择就好。
8. 解决冲突
假设这样一个场景，A和B两位同学各自开了两个分支来开发不同的功能，大部分情况下都会尽量互不干扰的，但是有一个需求A需要改动一个基础库中的一个类的方法，不巧B这个时候由于业务需要也改动了基础库的这个方法，因为这种情况比较特殊，A和B都认为不会对地方造成影响，等两人各自把功能做完了，需要合并的到主分支 master 的时候，我们假设先合并A的分支，这个时候没问题的，之后再继续合并B的分支，这个时候想想也知道就有冲突了，因为A和B两个人同时更改了同一个地方，Git 本身他没法判断你们两个谁更改的对，但是这个时候他会智能的提示有 conflicts ，需要手动解决这个冲突之后再重新进行一次 commit 提交。我随便在项目搞了一个冲突做下示例：
以上截图里就是冲突的示例，冲突的地方由 ==== 分出了上下两个部分，上部分一个叫 HEAD 的字样代表是我当前所在分支的代码，下半部分是一个叫 baidu_activity 分支的代码，可以看到 HEAD 对 gradle 插件进行了升级，同时新增了一个插件，所以我们很容易判断哪些代码该保留，哪些代码该删除，我们只需要移除掉那些老旧代码，而且同时也要把那些 «< HEAD、==== 以及 »»»baidu_activity 这些标记符号也一并删除，最后进行一次 commit 就ok了。
我们在开发的过程中一般都会约定尽量大家写的代码不要彼此影响，以减少出现冲突的可能，但是冲突总归无法避免的，我们需要了解并掌握解决冲突的方法。
mkdir test （创建文件夹test） cd test （切换到test目录） touch a.md （新建a.md文件）
这里提醒下：在进行任何 Git 操作之前，都要先切换到 Git 仓库目录，也就是先要先切换到项目的文件夹目录下。
这个时候我们先随便操作一个命令，比如 git status ，可以看到如下提示（别纠结颜色之类的，配置与主题不一样而已）：
意思就是当前目录还不是一个 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 log
这个时候我们输入 git log 命令，会看到如下：
git log 命令可以查看所有产生的 commit 记录，所以可以看到已经产生了一条 commit 记录，而提交时候的附带信息叫 ‘first commit’ 。
git add & git commit
看到这里估计很多人会有疑问，我想要提交直接进行 commit 不就行了么，为什么先要再 add 一次呢？首先 git add 是先把改动添加到一个「暂存区」，你可以理解成是一个缓存区域，临时保存你的改动，而 git commit 才是最后真正的提交。这样做的好处就是防止误提交，当然也有办法把这两步合并成一步，不过后面再介绍，建议新手先按部就班的一步步来。
git branch
branch 即分支的意思，分支的概念很重要，尤其是团队协作的时候，假设两个人都在做同一个项目，这个时候分支就是保证两人能协同合作的最大利器了。举个例子，A, B俩人都在做同一个项目，但是不同的模块，这个时候A新建了一个分支叫a， B新建了一个分支叫b，这样A、B做的所有代码改动都各自在各自的分支，互不影响，等到俩人都把各自的模块都做完了，最后再统一把分支合并起来。
执行 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
这个命令的意思就是新建一个a分支，并且自动切换到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 记录。
可以看到我新建了两个标签 v1.0、v1.1。
想要切换到某个tag怎么办？也很简单，执行 git checkout v1.0 ，这样就顺利的切换到 v1.0 tag的代码状态了。
OK，以上全是一些最基本的Git操作，而且全是在本地环境进行操作的，完全没有涉及到远程仓库，下一章节将以远程 GitHub 仓库为例，讲解下本地如何跟远程仓库一起同步协作，另外今天讲的全是最基础最简单的Git操作，一步步来，后续再继续讲解一下Git的高阶以及一些Git的酷炫操作。
另外，考虑到可能会有人嫌我讲解的太基础太慢，毕竟我是针对小白，所以得一步步来，迫不及待的想要提前自己学习的不妨在我公众号 AndroidDeveloper 回复「git」关键字，获取一份我推荐的还不错的 Git 学习资料，不谢，毕竟我这么帅！
1. SSH
你拥有了一个 GitHub 账号之后，就可以自由的 clone 或者下载其他项目，也可以创建自己的项目，但是你没法提交代码。仔细想想也知道，肯定不可能随意就能提交代码的，如果随意可以提交代码，那么 GitHub 上的项目岂不乱了套了，所以提交代码之前一定是需要某种授权的，而 GitHub 上一般都是基于 SSH 授权的。
那么什么是 SSH 呢？ 简单点说，SSH是一种网络协议，用于计算机之间的加密登录。目前是每一台 Linux 电脑的标准配置。而大多数 Git 服务器都会选择使用 SSH 公钥来进行授权，所以想要在 GitHub 提交代码的第一步就是要先添加 SSH key 配置。
2. 生成SSH key
Linux 与 Mac 都是默认安装了 SSH ，而 Windows 系统安装了 Git Bash 应该也是带了 SSH 的。大家可以在终端（win下在 Git Bash 里）输入 ssh 如果出现以下提示证明你本机已经安装 SSH， 否则请搜索自行安装下。
紧接着输入 ssh-keygen -t rsa ，什么意思呢？就是指定 rsa 算法生成密钥，接着连续三个回车键（不需要输入密码），然后就会生成两个文件 id_rsa 和 id_rsa.pub ，而 id_rsa 是密钥，id_rsa.pub 就是公钥。这两文件默认分别在如下目录里生成：
Linux/Mac 系统 在 ~/.ssh 下，win系统在 /c/Documents and Settings/username/.ssh 下，都是隐藏文件，相信你们有办法查看的。
接下来要做的是把 id_rsa.pub 的内容添加到 GitHub 上，这样你本地的 id_rsa 密钥跟 GitHub 上的 id_rsa.pub 公钥进行配对，授权成功才可以提交代码。
3. GitHub 上添加 SSH key
第一步先在 GitHub 上的设置页面，点击最左侧 SSH and GPG keys ：
然后点击右上角的 New SSH key 按钮：
需要做的只是在 Key 那栏把 id_rsa.pub 公钥文件里的内容复制粘贴进去就可以了（上述示例为了安全粘贴的公钥是无效的），Title 那栏不需要填写，点击 Add SSH key 按钮就ok了。
这里提醒下，怎么查看 id_rsa.pub 文件的内容？
Linux/Mac 用户执行以下命令：
cd ~/.ssh
cat id_rsa.pub
Windows用户，设置显示隐藏文件，可以使用 EditPlus 或者 Sublime 打开复制就行了。
SSH key 添加成功之后，输入 ssh -T git@github.com 进行测试，如果出现以下提示证明添加成功了。
4. Push & Pull
在提交代码之前我们先要了解两个命令，也是上次的文章没有介绍的，因为这两个命令需要跟远程仓库配合。
Push ：直译过来就是「推」的意思，什么意思呢？如果你本地代码有更新了，那么就需要把本地代码推到远程仓库，这样本地仓库跟远程仓库就可以保持同步了。
代码示例： git push origin master
意思就是把本地代码推到远程 master 分支。
Pull：直译过来就是「拉」的意思，如果别人提交代码到远程仓库，这个时候你需要把远程仓库的最新代码拉下来，然后保证两端代码的同步。
代码示例： git pull origin master
意思就是把远程最新的代码更新到本地。一般我们在 push 之前都会先 pull ，这样不容易冲突。
5. 提交代码
添加 SSH key 成功之后，我们就有权限向 GitHub 上我们自己的项目提交代码了，而提交代码有两种方法：
Clone自己的项目 我们以我在 GitHub 上创建的 test 项目为例，执行如下命令：
git clone git@github.com:stormzhang/test.git
这样就把 test 项目 clone 到了本地，你可以把 clone 命令理解为高级点的复制，这个时候该项目本身就已经是一个git 仓库了，不需要执行 git init 进行初始化，而且甚至都已经关联好了远程仓库，我们只需要在这个 test 目录下任意修改或者添加文件，然后进行 commit ，之后就可以执行：
git push origin master
进行代码提交，这种是最简单方便的一种方式。
至于怎么获取项目的仓库地址呢？如下图：
关联本地已有项目 如果我们本地已经有一个完整的 git 仓库，并且已经进行了很多次 commit ，这个时候第一种方法就不适合了。
假设我们本地有个 test2 的项目，我们需要的是在 GitHub 上建一个 test 的项目，然后把本地 test2 上的所有代码 commit 记录提交到 GitHub 上的 test 项目。
第一步就是在 GitHub 上建一个 test 项目，这个想必大家都会了，就不用多讲了。
第二步把本地 test2 项目与 GitHub 上的 test 项目进行关联，切换到 test2 目录，执行如下命令：
git remote add origin git@github.com:stormzhang/test.git
什么意思呢？就是添加一个远程仓库，他的地址是 git@github.com:stormzhang/test.git ，而 origin 是给这个项目的远程仓库起的名字，是的，名字你可以随便取，只不过大家公认的只有一个远程仓库时名字就是 origin ，为什么要给远程仓库取名字？因为我们可能一个项目有多个远程仓库？比如 GitHub 一个，比如公司一个，这样的话提交到不同的远程仓库就需要指定不同的仓库名字了。
查看我们当前项目有哪些远程仓库可以执行如下命令：
git remote -v
接下来，我们本地的仓库就可以向远程仓库进行代码提交了：
git push origin master
就是默认向 GitHub 上的 test 目录提交了代码，而这个代码是在 master 分支。当然你可以提交到指定的分支，这个之后的文章再详细讲解。
对了，友情提醒，在提交代码之前先要设置下自己的用户名与邮箱，这些信息会出现在所有的 commit 记录里，执行以下代码就可以设置：
git config —global user.name "stormzhang"
git config —global user.email "stormzhang.dev@gmail.com"
1. 用户名和邮箱
我们知道我们进行的每一次commit都会产生一条log，这条log标记了提交人的姓名与邮箱，以便其他人方便的查看与联系提交人，所以我们在进行提交代码的第一步就是要设置自己的用户名与邮箱。执行以下代码：
git config --global user.name "stormzhang"
git config --global user.email "stormzhang.dev@gmail.com"
以上进行了全局配置，当然有些时候我们的某一个项目想要用特定的邮箱，这个时候只需切换到你的项目，以上代码把 –global 参数去除，再重新执行一遍就ok了。
PS：我们在 GitHub 的每次提交理论上都会在 主页的下面产生一条绿色小方块的记录，如果你确认你提交了，但是没有绿色方块显示，那肯定是你提交代码配置的邮箱跟你 GitHub 上的邮箱不一致，GitHub 上的邮箱可以到 Setting -> Emails里查看。
2. alias
我们知道我们执行的一些Git命令其实操作很频繁的类似有：
git commit
git checkout
git branch
git status
...
这些操作非常频繁，每次都要输入完全是不是有点麻烦，有没有一种简单的缩写输入呢？比如我对应的直接输入以下：
git c
git co
git br
git s
...
是不是很简单快捷啊？这个时候就用到了alias配置了，翻译过来就是别名的意思，输入以下命令就可以直接满足了以上的需求。
git config --global alias.co checkout # 别名
git config --global alias.ci commit
git config --global alias.st status
git config --global alias.br branch
当然以上别名不是固定的，你完全可以根据自己的习惯去定制，除此之外还可以设置组合，比如：
git config --global alias.psm 'push origin master'
git config --global alias.plm 'pull origin master'
之后经常用到的git push origin master 和 git pull origin master 直接就用 git psm 和 git plm 代替了，是不是很方便？
另外这里给大家推荐一个很强大的 alias 命令，我们知道我们输入 git log 查看日志的时候是类似这样的：
告诉大家一个比较屌的命令，输入**git log –graph –pretty=format:’%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset’ –abbrev-commit –date=relative ** 然后日志这样了：
是不是比较清晰，整个分支的走向也很明确，但是每次都要输这么一大串是不是也很烦？这时候你就该想到 alias 啊：
git config --global alias.lg "log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative"
这样以后直接输入 git lg 就行了。
3. 其他配置
当然还有一些其他有用的配置，默认情况下 git 用的编辑器是 vi ，如果不喜欢可以改成其他编辑器，比如我习惯 vim 。
git config --global core.editor "vim" # 设置Editor使用vim
你们如果喜欢其他编辑器可自行搜索配置，前提是本机有安装。
有些人纳闷我的终端怎么有各种颜色，自己却不是这样的，那是因为你们没有开启给 Git 着色，输入如下命令即可：
git config --global color.ui true
还有些其他的配置如：
git config --global core.quotepath false # 设置显示中文文件名
以上基本所有的配置就差不多了，默认这些配置都在 ~/.gitconfig 文件下的，你可以找到这个文件查看自己的配置，也可以输入 git config -l 命令查看。
4. diff
diff命令算是很常用的，使用场景是我们经常在做代码改动，但是有的时候2天前的代码了，做了哪些改动都忘记了，在提交之前需要确认下，这个时候就可以用diff来查看你到底做了哪些改动，举个例子，比如我有一个 a.md 的文件，我现在做了一些改动，然后输入 git diff 就会看到如下：
红色的部分前面有个 - 代表我删除的，绿色的部分前面有个 + 代表我增加的，所以从这里你们很一目了然的知道我到底对这个文件做了哪些改动。
值得一提的是直接输入 git diff 只能比较当前文件和暂存区文件差异，什么是暂存区？就是你还没有执行 git add 的文件。
当然跟暂存区做比较之外，他还可以有其他用法，如比较两次 commit 之间的差异，比较两个分支之间的差异，比较暂存区和版本库之间的差异等，具体用法如下：
git diff <$id1> <$id2> # 比较两次提交之间的差异
git diff <branch1>..<branch2> # 在两个分支之间比较
git diff --staged # 比较暂存区和版本库差异
5. 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 进暂存区的文件。
6. 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 是清空。
7. merge & rebase
我们知道 merge 分支是合并的意思，我们在一个 featureA 分支开发完了一个功能，这个时候需要合并到主分支 master 上去，我们只需要进行如下操作：
git checkout master
git merge featureA
其实 rebase 命令也是合并的意思，上面的需求我们一样可以如下操作：
git checkout master
git rebase featureA
rebase 跟 merge 的区别你们可以理解成有两个书架，你需要把两个书架的书整理到一起去，第一种做法是 merge ，比较粗鲁暴力，就直接腾出一块地方把另一个书架的书全部放进去，虽然暴力，但是这种做法你可以知道哪些书是来自另一个书架的；第二种做法就是 rebase ，他会把两个书架的书先进行比较，按照购书的时间来给他重新排序，然后重新放置好，这样做的好处就是合并之后的书架看起来很有逻辑，但是你很难清晰的知道哪些书来自哪个书架的。
只能说各有好处的，不同的团队根据不同的需要以及不同的习惯来选择就好。
8. 解决冲突
假设这样一个场景，A和B两位同学各自开了两个分支来开发不同的功能，大部分情况下都会尽量互不干扰的，但是有一个需求A需要改动一个基础库中的一个类的方法，不巧B这个时候由于业务需要也改动了基础库的这个方法，因为这种情况比较特殊，A和B都认为不会对地方造成影响，等两人各自把功能做完了，需要合并的到主分支 master 的时候，我们假设先合并A的分支，这个时候没问题的，之后再继续合并B的分支，这个时候想想也知道就有冲突了，因为A和B两个人同时更改了同一个地方，Git 本身他没法判断你们两个谁更改的对，但是这个时候他会智能的提示有 conflicts ，需要手动解决这个冲突之后再重新进行一次 commit 提交。我随便在项目搞了一个冲突做下示例：
以上截图里就是冲突的示例，冲突的地方由 ==== 分出了上下两个部分，上部分一个叫 HEAD 的字样代表是我当前所在分支的代码，下半部分是一个叫 baidu_activity 分支的代码，可以看到 HEAD 对 gradle 插件进行了升级，同时新增了一个插件，所以我们很容易判断哪些代码该保留，哪些代码该删除，我们只需要移除掉那些老旧代码，而且同时也要把那些 «< HEAD、==== 以及 »»»baidu_activity 这些标记符号也一并删除，最后进行一次 commit 就ok了。
我们在开发的过程中一般都会约定尽量大家写的代码不要彼此影响，以减少出现冲突的可能，但是冲突总归无法避免的，我们需要了解并掌握解决冲突的方法。
==============================================================
生成多个公钥私钥的方法。
$ ssh-keygen -t rsa -C "373614724@qq.com"
下面就继续输入你公私钥的地址， 命名规则 要 在后面加 _rsa 不然会有乱码。
/c/Users/MYPC/.ssh/myabc_rsa
扫一扫
1244
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
