GIT基础
GIT进阶
IDEA Pull
git pull 是 git fetch + git merge FETCH_HEAD 的缩写。
git pull就是先fetch，然后执行merge 操作，如果加--rebase参数，就是使用git rebase 代替git merge。
Idea update project 就是你可以选择到底是merge 还是 rebase 的git pull
stash shelve的区别
https://www.oschina.net/question/948439_2231748
cherry-pick
cherry-pick类似于一个定制化的merge，它可以把其它分支上的commit一个个摘下来，合并到当前分支。
Git 打补丁– patch 和 diff 的使用
https://www.jianshu.com/p/ec04de3f95cc
Git标签
如果你达到一个重要的阶段，并希望永远记住那个特别的提交快照，你可以使用 git tag 给它打上标签
git tag -a v1.0 //-a 带注解的标签
回到merge之前的代码
git rebase/merge --abort 回到执行 rebase 之前
GIT高级
分支策略
https://www.w3cschool.cn/git/git-4nu52kvb.html
https://zhuanlan.zhihu.com/p/108385922
分支环境
Git 分支规范之前，先说下在系统开发过程中常用的环境。
- DEV 环境：用于开发者调试使用。
- FAT 环境：功能验收测试环境，用于测试环境下的软件测试者测试使用。
- UAT 环境：用户验收测试环境，用于生产环境下的软件测试者测试使用。
- PRO 环境：就是生产环境。
分支
| 分支 | 名称 | 环境 |
|---|---|---|
| master | 主分支 | PRO |
| release | 预上线分支 | UAT |
| develop | 测试分支（主要的开发分支） | FAT |
| feature | 需求开发分支 | 本地环境 |
| hotfix | 紧急修复分支 | 本地环境 |
master分支
master 为主分支，用于部署到正式环境（PRO），一般由 release 或 hotfix 分支合并，任何情况下不允许直接在 master 分支上修改代码。如果你达到一个重要的阶段，打一个发布版本的 tag。
release 分支
release 为预上线分支，用于部署到预上线环境（UAT），始终保持与 master 分支一致，一般由 develop 或 hotfix 分支合并，不建议直接在 release 分支上直接修改代码。
如果在 release 分支测试出问题，需要回归验证 develop 分支看否存在此问题。
develop 分支
develop 为测试分支，用于部署到测试环境（FAT），始终保持最新完成以及 bug 修复后的代码，可根据需求大小程度确定是由 feature 分支合并，还是直接在上面开发。
一定是满足测试的代码才能往上面合并或提交。
feature 分支
feature 为需求开发分支，命名规则为 feature- 开头，一旦该需求上线，便将其删除。
hotfix 分支
hotfix 为紧急修复分支，命名规则为 hotfix- 开头。
当线上出现紧急问题需要马上修复时，需要基于 release 或 master 分支创建 hotfix 分支，修复完成后，再合并到 release 或 develop 分支，一旦修复上线，便将其删除。
新需求加入
有一个订单管理的新需求需要开发，首先要创建一个 feature-order 分支，问题来了，该分支是基于哪个分支创建？
如果 存在 未测试完毕的需求，就基于 master 创建。
如果 不存在 未测试完毕的需求，就基于 develop 创建。
- 需求在
feature-order分支开发完毕，准备提测时，要先确定develop不存在未测试完毕的需求，这时研发人员才能将将代码合并到develop（测试环境）供测试人员测试。 - 测试人员在
develop（测试环境） 测试通过后，研发人员再将代码发布到release（预上线环境）供测试人员测试。 - 测试人员在
release（预上线环境）测试通过后，研发人员再将代码发布到master（正式环境）供测试人员测试。 - 测试人员在
master(正式环境) 测试通过后，研发人员需要删除feature-order分支。
Commit 日志规范
建议参考规范：<type>(scope)：<subject>
比如：fix(首页模块)：修复弹窗 JS Bug。
type 表示 动作类型，可分为：
- fix：修复 xxx Bug
- feat：新增 xxx 功能
- test：调试 xxx 功能
- style：变更 xxx 代码格式或注释
- docs：变更 xxx 文档
- refactor：重构 xxx 功能或方法
scope 表示 影响范围，可分为：模块、类库、方法等。
subject 表示 简短描述，最好不要超过 60 个字，如果有相关 Bug 的 Jira 号，建议在描述中加上。
Reabase在新位置重新提交
git merge和git rebase的区别, 切记：永远用rebase
在开发过程中使用git rebase还是git merge，优缺点分别是什么？
洁癖者用 Git：pull –rebase 和 merge –no-ff
rebase ：翻译：变基
rebase 的意思是，给你的 commit 序列重新设置基础点
展开来说就是，把你指定的commit 以及它所在的 commit 串，以指定的目标 commit 为基础，依次重新提交一次。
rebase可以确保生产分支commit是一个线性结构，方便rollback
git rebase 目标基础点
Rebase步骤
//切到feature分支，重新设置基准点，此时基准从2变为4 此时feture变为 1 -> 2 -> 3 -> 4 -> 7 -> 8
git checkout feature
git rebase master
//切换到master分支，merge feature 此时maste变为1 -> 2 -> 3 -> 4 -> 7 -> 8
git checkout master
git merge feature
为什么不直接在master上执行Rebase
虽然rebase后的commit 虽然 内容相同，但是不同的commits
如果在master rebase
则master变为1 -> 2 -> 5 -> 6 -> 7 -> 8，3和4丢失，与远程仓库不一致
总结
rebase的最大好处并不是消除merge，而是避免merge的交织。
简要来说，就是在merge进被合分支（如master）之前，最好将自己的分支给rebase到最新的被合分支（如master）上，然后用pull request创建merge请求。
一人多任务
https://blog.csdn.net/ericwang_1992/article/details/54136733
刚才提交的代码发现有错误怎么办
可以再写一个commit 不过最优雅的方式是：commit --amend， IDEA勾选amend选项 。
在提交时，如果加上–amend 参数，Git 不会在当前 commit 上增加commit ，而是会把当前 commit 里的内容和暂存区（stageing area）里的内容合并起来后创建一个新的 commit ，用这个新的 commit 把当前commit 替换掉。
丢弃刚写的提交Reset
git reset --hard 目标commit
想丢弃的不是最新的提交
rebase
//TODO
代码已经push发现错了
出错内容在本地
–amend 修改 push – force强制push 这样push到自己分支的提交就会被修改
紧急情况，立马打个包
stash: 临时存放工作目录的改动
stash: 翻译 藏匿
stash指令可以把你工作目录里的内容放到你本地的一个独立的地方，他不会被提交，也不会被删除。
你可以去做你的临时工作，做完之后来取走，就可以继续手头的工作。
Branch删除之后还有用
reflog：引用的log
使用它可以查看 Git 仓库中的引用的移动记录。如果不指定引用，它会显示 HEAD 的移动记录。
被删除之前的位置了，也就是第二行的 c08de9a
git checkout c08de9a
git checkout -b branch1 这样，你刚删除的 branch1 就找回来了
git reflog master 也可以手动加上名称来查看其他引用的移动历史