git命令
常见命令：
1、克隆远程仓库
git clone ......
2、git add . 将所有修改过的文件提交暂存区
3、git diff 比较当前目录和暂存区中的差异
4、git status 掌握当前分支的状态
5、分支管理
git br -r 查看远程分支 git br <new_branch>创建新的分支 git br -v 查看各个分支最后提交的信息 git branch 显示当前所有分支 git checkout <your_branch>切换分支 git checkout -b <new_branch> 创建并切换分支
git br -d <your_branch> 删除分支 前提是先要切换到其他分支
分支合并：
git checkout master 切换到master分支
git merge my_branch 将my_branch分支合并到master分支上
6、版本回退 git reset
假如我们本次提交(commit)到本地仓库的内容错误，我们需要返回到上一版本。
首先通过 git log查看历史记录，可以看到我们所有提交的版本（从近到远）
在Git中，用HEAD表示当前版本，也就是最新提交的版本，上一个版本就是HEAD^，上上个版本就是HEAD^^
git reset --hard HEAD^
git revert：如果我们想撤销之前的某一版本，但是有想要保留该目标版本之后的版本，就可以用git revert
原理：
用于“反做”某一版本，以达到撤销该版本的修改的目的。比如我们commit了三个版本（版本一、版本二、版本三），突然发现版本二不行（有bug），想要撤销版本二，但是又不想影响版本三的提交，就可以用git revert命令来反做版本二，生成新的版本四，这个版本里会保留版本三的东西，但是撤销了版本二的东西。
先通过git log找到版本二的版本号，然后使用“git revert -n 版本号”反做，并使用“git commit -m 版本号”提交。
提交代码：
（1）git status
（2）git add .
（3）git commit -m "message" 将暂存区代码提交到本地仓库。若文件未提交到暂存区，则提交时不会提交任何修改。
（4）
（5）git push origin <主分支> 将本地的分支推送到远程的对应分支上
拉取指定分支代码合并到当前分支：
git pull origin dev
注意：使用该命令前，需保证本地工作区是没有任何修改代码的，也就是说需要将本地工作区编辑过的文本添加到暂存区（git add .）或提交到本地仓库中（git commit），才能使用该命令拉取指定分支的代码合并到当前分支中。
每次操作完git commit命令后，必须拉一下主分支代码，保证本地正在开发功能逻辑的分支代码是最新的，避免后续在提交时冲突过多或覆盖掉其他人的代码问题出现。
拉取最新代码并合并可能出现的情况：
-
已是最新代码：Already up-to-date
-
拉取的主干分支被修改：
-
拉取代码时发生冲突：自动合并失败，修改冲突然后提交修改后的结果。
CONFLICT(content)，这个词的出现表明某一个具体文件在合并过程中发生了冲突。发生冲突的原因大致可以理解为你与你的同事两个人在同一个文件中都进行了编辑操作，当其中一个人拉取合并了另一个人的分支，或拉取合并了另一个人合并过的分支的话，就会出现合并冲突的问题。
pull相当于git fetch和git merge，即更新远程仓库的代码到本地仓库，然后将内容合并到当前分支；
git fetch：从远程获取最新版本到本地，不会自动merge
git merge：将内容合并到当前分支
git pull：从远程获取最新版本并merge到当前分支
git merge和git rebase的区别（都用于分支合并）
git merge：将两个分支合并提交为一个新提交，并且新提交有两个parent。
merge好在它是一个安全的操作，现有的分支不会更改。将两个分支的历史连在了一起。
git rebase：会取消分支中的每个提交，并把它们临时存放，然后把当前分支更新到最新的origin分支，最后再把所有暂存的提交应用到分支上。
rebase为原分支上每个提交创建一个新的提交，重写了项目历史，并且不会带来合并提交。
优缺点：
rebase最大的好处就是你的项目历史会非常整洁，rebase导致最后的项目历史呈现出完美的线性。你可以从项目终点到起点浏览而不需要任何的fork，这更容易使用git log来查看项目历史。
rebase不会有合并提交中带的附加信息——你看不到该分支并入了上游的哪些更改。
如何选择使用merge还是rebase？
如果你想要一个干净的、线性的提交历史，没有不必要的合并提交，你应该使用 git rebase 而不是 git merge 来并入其他分支上的更改。
另一方面，如果你想要保存项目完整的历史，并且避免重写公共分支上的 commit， 你可以使用 git merge。两种选项都很好用，但至少你现在多了 git rebase 这个选择。
假设基于远程分支”origin“，创建了一个叫”mywork“的分支。
git checkout -b mywork
然后我们在这这个分支上做一些修改，生成两个提交；但是与此同时，有些人也在“origin”分支上做了一些修改并且做了提交，这就意味着“origin”和“mywork”这两个分支各自都前进了，一直它们之间“分叉”了。
在这里我们可以用git pull命令把“origin”远程分支上的修改拉下来并且和你的修改合并，结果看起来像是一个新的“合并的提交”。
但是，如果我们想让“mywork”分支历史看起来像没有经过任何合并一样，可以使用git rebase。
git checkout mywork
git rebase origin
这些命令会把你的“mywork”分支里的每次提交（commit）取消掉，并且把他们临时保存在补丁（这些补丁放到“.git/rebase”目录中），然后把“mywork”分支更新到最新的“origin”分支上，最后把保存的这些补丁应用到“mywork”分支上。
在rebase的过程中，也许会出现冲突的情况，此时git会停止rebase并会让你去解决冲突；在解决完冲突后，用“git-add”命令去更新这些内容的索引，然后，无需执行 git-commit命令，只需执行 git rebase --continue,git就会继续应用余下的补丁。
