重新了解的git以及git的工作场景

git的四大状态

untrack，modified，committed和staged

untrack

没有记录的文件，就是新创建的文件

modified

修改过的文件，和版本库里的文件不一致

staged

暂存，把改动记录下来。执行完git add之后，得到的状态就是staged

committed

执行了git commit ，相当于把暂存区的代码提交到本地库中

git的分区

工作区：我们写的代码文件目录
暂存区：git add 之后，就在暂存区了
版本库：git commit 之后，就在本地版本库了
远程仓库： git push 之后，就在远程仓库了

合并分支

1.快速合并：Fast-forward

注意到上面的Fast-forward信息，Git告诉我们，这次合并是“快进模式”，也就是直接把master指向dev的当前提交，所以合并速度非常快。

2.解决冲突

在master分支上git merge feature1
产生冲突

git status查看冲突文件

在master分支解决完冲突后

git log --graph --pretty=oneline --abbrev-commit 查看日志即可查看到分支信息

merge原理

我们使用merge进行合并的时候，都是一行行的进行合并，会出现2种情况：1.自动合并2.产生冲突

三路合并

2个分支的文件，会先找到一个之前的祖宗进行合并，如果2个文件相对祖宗都发生了改变，那就会产生冲突；
否则，git自动取相对于祖宗发生改变的为结果

工作场景

正在开发功能，此时需要紧急修复bug

1.git stash 把正在工作的代码存起来。
2.git status 查看工作区是否干净
3.git checkout master 切换到master分支
4.git checkout -b hotbug 创建bug分支
5.git add . git commit -m"bug"
6.git checkout master
7.git merge --no-ff -m "合并分支" bug
8.git stash list查看之前的工作代码
9.git stash pop恢复之前的工作代码
10.继续工作啦~~~~~~

在master分支修复了bug，dev分支是早期从master分支出来的，所以这个bug在dev分支上也有

第一种方法把master分支合并到dev，git merge dev
第二种方法只复制bug分支所作的修改 git cherry-pick 分支编号

同事写好的功能分支，需要合到dev分支

和同事确认是否在基于dev分支创建的
在dev分支上merge 功能分支，
不需要同事合并dev分支，这样会带来很多更新记录，不利于查看更改记录和不可控

dev分支上线完成后，需要合并到master分支

因为dev分支上有很多提交记录，因此采用这个命令来合并

git merge --squash origin/dev    合并dev分支，上传提交记录