git仓库的主要组成
git仓库主要有三大部分：工作区、暂存区和版本库，其中，工作区就是我们存放各种文件的地方。 当我们调用git add时，就会将对文件的改变存放到.git隐藏文件夹的object库中，而我们的暂存区其实也叫做索引，里面维护着指向缓存区对象的指针，而我们调用git commit 时，就会将这个指针 链表重新组合，在我们的head所指向的master分支（不一定）创建出新的各个节点指向object库中对象 文件的链表。 git帮助我们管理文件，实际上管理的并不是文件，而是对文件的更改。
查看commit信息，查看object库中对象的具体内容
使用git log可以查看commit信息，但是这种读取方式会导致文件过长，可以采取--pretty=oneline的方式来进行美化；如果想要查看对象库中某个对象的内容，可以采用git cat-file的方式来读取已经哈希加密的文件更改，如git cat-file -p commit_id，这里的commit_id，其实就是object对象的编号
使用git status可以查看上次提交后当前文件与提交过的文件相比是否发生变化。
而想要查看具体差异情况，可以通过git diff filename来查看当前工作区与暂存区代码的区别
git 版本控制
版本回退的概念：
本质上回退的是版本库中的内容
git reset
git reset [--soft | --mixed | --hard] [HEAD]
soft：只回退版本库中的内容，不更改工作区
mixed：既回退版本库，又回退暂存区
hard：回退版本库、暂存区、工作区的所有内容
hard慎用，会导致当前工作区中的所有内容消失
当终端中没有清楚掉commidID，可以撤销reset指令；但是当已经清空屏幕时，可以使用git reflog来查看本地每一次提交的commimID
回退过程是很快的，因为只是修改了.git/ref/head所指向的master所指向的object库中的提交对象
撤销修改
|----------|----------|----------|
| 工作区 | 暂存区 | 版本库 |
| xxx code | | |
| xxx code | xxx code | |
| xxx code | xxx code | xxx code |
- 第一种情况:使用git checkout -- filename 来将暂存区中最近一次更改回退到工作区
- 第二种情况：回退暂存区中的内容，使用如下命令后，再调用git status就会发现暂存区内容被清空，工作区内容被更改
使用git reset HEAD filename，可以在HEAD后加上^来表示回退到上几个版本 - 第三种情况：使用git reset --option commit_id，但是一旦调用过了push，那么就不能这么处理了
撤销，就是为了防止不好的代码推送到远程仓库中。
删除文件
方法一：手动删除，工作区rm，然后add，commit，三步
方法二：使用git rm filename，会自动删除暂存区中的内容，只需手动提交，节省了一步
git分支的概念
HEAD所指向的master就是一个分支，查看当前仓库中有哪些分支：git branch
HEAD不仅可以指向master分支，还可以指向任意一个分支，被head指向的分支，才是我们的工作分支
需要创建分支时，同样采取git branch branch_name，切换分支采取git checkout branch_name
我们在两个分支上提交的代码是互不影响的，add和commit都只在当前工作分支生效
合并分支：
采取git merge branch_name的方法，但是需要被merge的分支中的所有内容都已经添加到版本库当中
分支合并模式：fastforward就是让我们的master直接指向我们的dev分支的当前提交，当然也有其他
合并模式，而且fastforward也不是每次都可以成功
合并分支和切换分支整合:git checkout -b dev1
删除分支：
使用git branch -d，但是需要注意的是，git branch -d只能
在非删除分支上删除分支。
因为创建、合并、修改分支是非常快速方便的，所以git鼓励使用分支进行工作
合并冲突
<<<<<<< HEAD
2
=======
1
>>>>>>> dev2merge冲突需要手动解决，并且需要进行一次提交操作------冲突发生时，先git add，再git commit, 最后
merge就可以解决冲突问题.
实际上就是这样的过程：
head--->mester
⬇️
master-----------------
/
dev ------------ git也支持查看具体的merge情况，使用git log --graph --abbrev-commit
分支策略：
dev分支，一般是开发环境，不稳定存在bug；经过一系列测试之后，将代码合并到master分支上；master主分支，线上环境，如app、网站等。
bug分支：
当master分支发生bug时，如果正在工作，现在需要去修复bug，那么就需要使用git stash来暂存我们
工作内容（不适合commit，因为尚未完成），此时可以切换branch到bug分支。这时，就可以进行bug
修复了，修复完成之后，就可以将bug分支和master分支进行合并。
之后进行git stash pop来取出我们暂存的工作内容，继续进行开发。
分支合并顺序的建议:
建议合并是先将master分支合并到自己的dev分支，处理好合并冲突之后，再将自己的dev分支合并到
master分支，这样理论上就不需要在master分支上进行冲突处理了。
git远程操作：
git是一个分布式版本控制系统，每个人的电脑上都可以有一个仓库。但是一旦本地仓库丢失，就意味
着所有文件的丢失。所以有一个中央服务器，7*24小时工作，将仓库复制到每个人的电脑上
在仓库中，主要有以下角色：管理员、开发者、观察者、报告者。当开发者请求合并到master分支时
，需要向管理员提交PR（合并申请单），阐述合并原因、新增功能等等。管理员同意后，才可以进行合并，在网站上使用Pull Request，即PR。
管理忽略文件
采取.gitignore文件，其中*.so的语法格式表示忽略所有的so文件，而如果需要排除某些文件，
则使用!b.so表示b.so仍需被git追踪管理.
git也提供了如何查看一个文件为何被忽略的方法，使用git check-ignore -v filename来查看忽略
原因，会打印.gitignore的具体忽略内容.
配置命令别名：
git config --global alias.name command（对于多个指令使用''）
要注意的是不能只给选项取别名，要连带命令一起
标签：
使用git tag 来查看已有标签，git tag tag_name来添加标签，加上-m选项来增加备注，使用git tag -d 删除标签，git show tag_name来查看某一标签信息及其对应的commit，使用tags来查看所有
标签。
多人协作
使用git checkout -b local_branch origin/remote_branch来链接本地仓库分支和远程分支，这样理论上就不需要在master分支上进行冲突处理
就可以使用git push / git pull的短命令了
创建分支：
建议远程创建分支，这样创建的分支就是最稳定最新的内容了。
在本地新建分支时，创建分支并完成工作需要push时，直接push是不可以的，因为没有建立链接。
使用git push origin new_branch_name就可以完成在远端新建分支并push
但是这样仍然没有完成连接的内容
进行连接：git branch --set-upstream-to=origin/remote_branch local_branch
对于短的git pull内容：
- 拉取分支内的内容，需要建立连接
- 拉取远程仓库的内容
解决 git branch -a总是显示出远程已删除的分支：
git remote show查看远程仓库中的各个分支及其状态，其中会显示远程仓库中哪个分支已经删除。
使用git remote prune origin来清除git branch -a中的相应远程分支，至于本地分支处理使用
git branch -d 即可.
git FLOW模型
git分支设计规范：
++master主分支++ ，生产环境，只读且唯一稳定的代码分支，一般有release合并得到，不允许直接在master分支上做任何代码更改，同时在master分支上的修改也应该带上标签tag
++release预发布分支++ ，一般有develop分支合并而来，交给测试进行测试，合并到master分支之后可以删除该分支
++develop开发分支++ ，基于master创建的一个唯一且只读的分支，始终保持最新且bug修复的代码，可以直接部署到开发环境对应集群，一般不允许在develop分支上直接进行开发
++feature需求开发分支++ ，进行功能开发后，合并到develop分支
hotfix分支，紧急bug修复，一旦出现bug，需要由master分支创建，修复bug后将其合并到master分支和develop分支，之后可以将其删除