0.认识git
git就是一个版本控制器，记录每次的修改以及版本迭代的一个管理系统
至于为什么会有git的出现，主要是为了解决一份代码改了又改，但最后还是要第一版的情况
- git 可以控制电脑上所有格式的文档
1.安装git
- sudo yum install git -y
2.基本操作
2.1 初始化本地仓库-git init
.git这个文件是用来追踪管理仓库的
- mkdir gitcode
- cd gitcode
- git init
2.2 新增配置项
- git config user.name "xxxx"
- git config user.email "xxxxx"
- 查看配置项： git config -l
- 重置配置项：git config --unset user.name/user.email
- 加了global之后就是配置的全局
- git config -global user.name "xxxx"
- git config -global user.email "xxxxx"
- 重置配置项：git config --global --unset user.name/user.email
2.3 工作区 && 暂存区 && 版本库
- 使用git add时，是把文件放入到了版本库中的暂存区中，也有index索引
- 使用git commit时，通过HEAD指针，将文件提交到master中的各个分支中
- 而git能实现版本控制是通过objects实现的，修改的工作区内容会写入对象库的一个新的git对象中
2.4 添加 && 提交
- git add文件名(一个或多个)
- git commit -m "这次提交的日志信息"
2.5 查看.git文件
- 由于之前进行了代码的提交，.git中也出现了index索引 ，而HEAD指针是指向的第一个文件的gitID ,也就是我们之前提交的那个文件，并且通过 git cat-file -p gitID，也可以查看文件的信息
2.6 修改文件 && 查看文件状态
- git status
- git diff文件名
2.7 版本回退 && 查看历史版本
|----------------------------|---------|---------|---------|
| | 工作区 | 暂存区 | 版本库 |
| git reset -- sort | 无 | 无 | 有影响 |
| git reset -- mixed(默认) | 无 | 有影响 | 有影响 |
| git reset -- hard(慎重) | 有影响 | 有影响 | 有影响 |
- git log --pretty=oneline #查看历史版本
- git reflog --pretty=oneline #查看历史所以版本
- git reset --sort --mixed --hard #版本回退
2.8 撤销修改
注：^表示上一版本，^^表示上二个版本
这些撤销操作都不会影响远程仓库的代码，因为没git push
|----------|----------|----------|------------------------------------------------------------------------|
| 工作区 | 暂存区 | 版本库 | 解决方式 |
| xxx code | | | 1.手动撤销 -- 不推荐，容易出差 2.git checkout-- [filename] -- 推荐 |
| xxx code | xxx code | | git reset --hard HEAD [filename] git checkout-- [filename] |
| xxx code | xxx code | xxx code | git retset --hard HEAD^ |
- git checkout-- [filename] -- 推荐
- git reset --hard HEAD [filename]
- git checkout -- [filename]
- git retset --hard HEAD^
2.9 删除文件
- **git rm [filename]**会删除工作区，暂存区中的文件
3. 分支管理
3.1 理解分支
- git 版本库中有个HEAD指针，指向master 主分支，指向的是最新一次提交
- 既然master是主分支 ，那么自然就可以在它的基础上，创建分支 && 合并分支
3.2 创建&&切换&&合并分支
查看当前分支： git branch
- 创建分支： git branch [分支名]
- 切换分支：git chekout [分支名]
- 在dev分支下对Readme文件，多增加了一行代码，dev中HEAD指针指向的是最新一次修改
- 所以dev分支和master分支中看到的Readme文件是不同的
- 合并分支：git merge [分支名]
3.3 删除分支
- 删除分支：git branch -d [filename]
3.4 合并冲突
- 合并分支发生了冲突，因为master分支和dev分支都对Readme文件进行了修改，
- 导致git不知道该怎么合并了
**解决办法：**手动修改解决冲突，重新add 和commit
- 查看分支以图形结构显示：git log --graph --abbrev-commit
- 简短的查看日志：git log --pretty=oneline --abbrrev-commit
3.5 合并模式
- 使用git merge [分支名]，合并的分支是看不出结构的(在回顾日志的时候
- 推荐在合并分支时：git merge --no-ff -m "xxx" [分支名]
3.6 分支策略
3.7 bug分支
假如我们现在正在 dev 分⽀上进⾏开发，开发到⼀半，突然发现master 分⽀上⾯有 bug，需要 解决
- git stash 命令，可以将当前的⼯作区信息进⾏储藏，被储藏的内容可以在将来某个时 间恢复出来( git stash pop )
- 储藏 dev ⼯作区之后，由于我们要基于master分⽀修复 bug，所以需要切回 master 分⽀，再新建临时分⽀fix-bug来修复 bug
- 之后再把fix-bug 和 master分支合并
3.8 强制删除分支
- 强制删除分支 git branch -D [分支名]
4. 远程操作
4.1 理解分布式版本控制系统
4.2 创建远程仓库
4.3 克隆远端仓库-HTTPS
- 克隆远端仓库：git clone 地址
4.5 克隆远端仓库-SSH
ssh的链接会以https链接更加安全，因为克隆远端仓库，需要配置公钥
- ssh-keygen -t rsa -C "邮箱名字"
- cat .ssh/id_rsa.pub #查看公钥
4.6 向远端仓库推送
- 向远端仓库推送：git push
4.7 拉取远程仓库
- 当远端仓库 比 本地仓库更新的时候，就可以进行pull操作**(本质就是2个分支的合并)**
- 拉取远程仓库 ：git pull origin master : master
4.8 忽略特殊文件
当在开发过程中，需要忽略一些文件，并将其不被提交时，可以添加到.gitignore
- !b.so表示b.so可以被git提交
4.9 配置命令别名
- 配置命令别名：git config --global alias.别名 '指令'
4.10 删除在本地显示远端也删除的分支
- 命令：git remote prune origin
- 将远程仓库的分支删除之后，再使用git branch -d 分支名，删除本地分支
5.标签
5.1 操作标签
- 添加标签：**git tag 标签名 gitID，****git tag -a 标签名 -m "xxx" gitID,**不写gitID默认是最新一次提交
- 查看所有标签：git tag
- 详细查看标签信息：git tag 标签名
- 删除标签：git tag -d 标签名
5.2 推送标签
- 将本地标签->远端：git push origin 标签名(推送某一个标签)，git push origin --tags(推送所有标签)
- 将本地删除的标签->远端：git push origin :标签名
6. 多人协作
同一分支下的多人协作 或不同分支下的多人协作
6.1 本地分支 与 远程分支关联
- 查看所有分支：git branch -a
- 关联分支：git checkout -b [分支名] origin/分支名
6.2 Pull Requst表单推送
- 使用这种办法进行合并分支到master中，有一个好处，最后这个表单(提交的各种代码信息)
- 项目经理就会查看一番，更加的安全，维护性也更好
7.企业级开发模型
7.1 企业级开发流程
7.2 系统开发环境
7.3 git分支设计模型
|---------|--------|----------|
| 分⽀ | 名称 | 适⽤环境 |
| master | 主分⽀ | ⽣产环境 |
| release | 预发布分⽀ | 预发布/测试环境 |
| develop | 开发分⽀ | 开发环境 |
| feature | 需求开发分⽀ | 本地 |
| hotfix | 紧急修复分⽀ | 本地 |
master 分⽀
- master 为主分⽀，该分⽀为 只读且唯⼀分⽀ 。⽤于部署到正式发布环境，⼀般由合并
release 分⽀得到 - 主分⽀作为稳定的唯⼀代码库,任何情况下不允许直接在 master 分⽀上修改代码
- 产品的功能全部实现后，最终在master分⽀对外发布，另外所有在master分⽀的推送应该 打标签 (tag） 做记录，⽅便追溯
- master 分⽀不可删除。
release 分⽀
- release 为预发布分⽀，基于本次上线所有的 feature 分⽀合并到 develop 分⽀之后，基
于 develop 分⽀创建。可以部署到测试或预发布集群 - 命名以 release/ 开头，建议的命名规则: release/version_publishtime 。
- release 分⽀主要⽤于提交给测试⼈员进⾏功能测试。发布提测阶段，会以 release 分⽀代码
为基准进⾏提测
- release 分⽀主要⽤于提交给测试⼈员进⾏功能测试。发布提测阶段，会以 release 分⽀代码
- 如果在 release 分⽀测试出问题，需要回归验证 develop 分⽀看否存在此问题
- release 分⽀属于临时分⽀，产品上线后可选删除
develop 分⽀
- develop 为开发分⽀，基于master分⽀创建的只读且唯⼀分⽀，始终保持最新完成以及 bug 修
复后的代码。可部署到开发环境对应集群。 - 可根据需求⼤⼩程度确定是由 feature 分⽀合并，还是直接在上⾯开发（⾮常不建议
feature 分⽀
- feature 分⽀通常为新功能或新特性开发分⽀，以 develop 分⽀为基础创建 feature 分
- 命名以 feature/ 开头，建议的命名规则： feature/user_createtime_feature
- 新特性或新功能开发完成后，开发⼈员需合到 develop 分⽀
- ⼀旦该需求发布上线，便将其删除
hotfix 分⽀
- hotfix 分⽀为线上 bug 修复分⽀或叫 补丁分⽀ ，主要⽤于对线上的版本进⾏ bug 修复。当线上
出现紧急问题需要⻢上修复时，需要基于 master 分⽀创建 hotfix 分 - ⽀
- 命名以 hotfix/ 开头，建议的命名规则: hotfix/user_createtime_hotfix
- 当问题修复完成后，需要合并到 master 分⽀和 develop 分⽀并推送远程。⼀旦修复上线，便
将其删除
- 当问题修复完成后，需要合并到 master 分⽀和 develop 分⽀并推送远程。⼀旦修复上线，便
7.4 企业级项目管理
=========================================================================