各位找工作实习的友友在工作之前一定要把git的相关知识掌握呀，我实现期间被leader说过关于git规范的相关问题了
目前已更新系列：
当前：:实习期间git的分枝管理以及最常用的命令
Redis高级----主从、哨兵、分片、脑裂原理-CSDN博客
计算机网络--面试总结四（HTTP、RPC、WebSocket、SSE）-CSDN博客
知识积累之ThreadLocal---InheritableThreadLocal总结
并发编程之----线程池ThreadPoolExecutor,Excutors的使用及其工作原理
1、分枝迭代规范
1. 基本规范：
-
- 基础分支
-
-
- master: 主开发分支，开发新代码从master分支checkout开发分支，开发测试完成合并回master分支，master分支可以保证基本稳定，但可能会有小bug
- release: 线上分支，基本上跟线上运行的代码版本一致（只有代码进release等待上线的短暂时间不一致），完全稳定的分支
- integration: 集成测试分支，每个sprint上线前会从master checkout integration分支进行集成测试
- gray-release: 灰度分支，每次集成测试通过后会从integration checkout gray-release分支进行灰度上线
-
-
- 其中针对会进行灰度的代码服务，四个分支都会有，其他的代码服务最少有2个基础分支：master和release
- 非灰度期间，灰度环境和线上环境的代码应该是时刻保持一致的。确保即便误操作导致流量进入到灰度环境，也不会引起问题
- 在以上四个基础分支的操作上，只允许有merge和checkout操作，不允许cherry-pick（只有临时发版有特例，参考
临时版本发布流程） - 哪个分支发现bug就在哪个分支checkout修复分支修复，修复完成合并回该分支
2. feature开发流程（个人/团队分支）
-
- 使用
git checkout master && git pull拉取当前最新的master分支 - 使用
git checkout -b <你的分支名>创建新分支 - 在新分支上进行开发，期间良好的习惯是经常性的通过
git checkout master && git pull更新master并git rebase/merge master来更新你的开发分支（merge还是rebase取决于是否有代码push到remote了，详细参照），避免一次性的更新引起很多conflict - 开发完毕后，再次更新master并合并到开发分支
- 使用
git push origin <你的分支名>将其推送到远端，建立merge request（mr），目标选择master（默认） - 找到对应的reviewer进行code review
- 找到对应的QA进行test
- review以及test完成后，将代码合并到master
- 使用
3. Hotfix流程（修复线上bug规范）
-
- 使用
git checkout release && git pull拉取最新的release分支 - 使用
git checkout -b <你的分支名>创建新分支 - 修复完毕后，再次使用
git checkout release && git pull拉取当前最新的release分支，并通过git merge release更新修复分支 - 确保bug修复后，使用
git push origin <你的分支名>将其推送到远端，建立MR，目标选择release（默认） - 找到对应的reviewer进行code review，review完成后合并到release分支
- hotfix发版前，由QA进行这次所有fix的统一测试，测试完成后将release发布到生产环境（QA通过jenkins上线任务执行）
- 将release合并回master/integration/gray-release（此步骤会通过jenkins上线任务自动执行），如果出现冲突，参考
4. release分支合并的冲突处理
- 使用
4. release分支合并的冲突处理
- 如果release合并回master的时候出现冲突进行如下处理
- 使用
git checkout release && git pull更新release- 在gitlab将临时分支合并到master
- 使用
git push origin <临时分支名>将临时合并分支推送到远端 - 解决完全部冲突后，使用 git commit 提交
- 根据git blame记录，找到对应的owner，进行冲突处理
- 使用
git checkout <临时分支名> && git merge origin/release从master checkout 临时分支，并在临时分支上执行合并，此时会出现冲突 - 使用
git checkout master && git pull更新master
- release合并回其他基础分支也是同样的操作，只不过把
master换成对应的integration或者gray-release
5. integration 以及 gray-release 上的fix
- 具体流程同Hotfix流程，只是将目标分支从release变成integration / gray-release
6. Sprint发版流程
- 双周迭代的第二周周三早9点，从master checkout integration分支开始进行集成测试，此时有3个有效分支：master/integration/release（jenkins任务定时自动执行）
- 周四晚上集成测试通过后，进行灰度发布（服务owner通过jenkins任务执行）
-
-
- 从integration checkout gray-release分支，进行灰度发布，同时删除integration分支，此时有三个有效分支：master/gray-release/release
- 在jenkins上，将本次需要上线的服务根据依赖关系逐一发布，有灰度支持的发布在灰度环境，没有的发布到线上
-
-
- 在确认发布成功后，将apollo的灰度列表设置为内部测试的几个org，进行内部验证（QA通过jenkins任务操作，周四晚上执行）
- 在内部验证完毕后，将更多的公司置入apollo灰度列表，开放灰度测试（QA通过jenkins任务操作，周五执行，持续时间周五到下周一）
- 在灰度测试完成后，发布代码到正式环境
-
-
- 将gray-release分支通过MR merge到release，并通过gitlab页面删除gray-release分支（各服务owner通过gitlab执行）
- 在jenkins上，进行release分支的发布到正式环境，并进一步发布到灰度环境，确保灰度环境和线上环境代码一致，最后将release分支合并回master（各服务owner通过jenkins任务执行）
- 在apollo上将灰度公司列表置空（QA通过jenkins任务操作）
-
-
- 删除分支的操作示意图如下：
7. 临时版本发布流程
-
- 临时版本的意思是在正常sprint上线之外，想要发布master里面部分代码到线上环境
- 由于在开发之初无法确定这次任务是否会临时发版，我们如果走正常流程会出现从master merge到release，将很多不希望这次上线的代码连带上线的问题，临时发版目前只能使用cherry-pick进行
- 具体流程是（开发owner执行）
-
-
- 测试通过后，将开发分支合并回master
- 通过
git checkout master && git pull更新master - 通过
git checkout release && git cherry-pick -m 1 #commit-id-of-merge-commit && git push将代码push到release - 代码发布后，将release合并回master，如果有冲突参考
4. release分支合并的冲突处理（jenkins自动执行）
-
- 带有灰度环境的开发流程示意图
- 无灰度的环境的开发流程示意图
rebase or merge?
- 如果local commit没有push到remote，推荐使用git rebase，因为rebase操作可以减少commit和merge的数量，让commit history干净清爽。
- 但如果已经push到remote上了，则只能使用git merge，禁止再rebase这个branch。这是因为rebase会修改git的commit history，导致local和remote的history不一致，你的朋友会抛弃你，你的亲人会离开你。详情可以去了解rebase的机制原理
- 例如：如果你想要更新local branch并且你的local commit 没有push到remote，使用git checkout master && git pull && git checkout your-dev-branch && git rebase master 而不是git merge
- rebase 操作分两种，第一种是rebase到当前分支之前的某次提交上，第二种是rebase到其他分支上。注意，第二种rebase操作只能做一次（也就是一旦rebase到某个分支上，就不能再rebase到其他分支上了），否则会引起commit记录混乱。
commit message
-
跟命名一样，message应该尽量precise and concise
-
commit message 格式：第一行简短说明该 commit 的主题，只写一句话。如果还有详细内容，则第二行留空，从第三行开始写详细描述。可以使用Markdown语法。例如：
Fix the bugs that can not open interview tab
- Change main-app route, add query string.
- Move 'InterviewTable' from /container to /component.
- Minor fix the style problem.
-
第一个词用动词一般式，并首字母大写
-
如果用英文不comfortable，也可以用中文
关于解conflict
- 如果merge有冲突，应该在解决冲突后立即做一次commit，并且使用默认的commit message
- 解决冲突时，只能修改冲突文件，不要修改非冲突文件。因为如果修改了其他文件，git会将这次提交当做一次新的commit而不是merge commit，相当于做了merge的操作但其实并没有merge，完了git强制你还得再merge一次。
- 不要在解决冲突的过程中修复bug和功能问题，即使这是由merge导致的。应该将这部分工作放在下一次commit中。
merge request过程
- 更新master
git checkout master && git pull
- 创建本地分支
git checkout -b <your_new_branch>
- 写代码并在本地提交
git commit
- 提交远程仓库
4.1. 首先更新master
git checkout master && git pull
4.2. 将你的分支rebase到最新的master
git checkout <your_new_branch> && git rebase -i master
如果有冲突，依次修复好conflict并继续rebase（参见下文如何解conflict），直到rebase过程完成
git rebase --continue
4.3. 提交至远程仓库
git push origin <your_new_branch>
注意 一旦将你的提交push至remote，就不允许再进行rebase操作了。见上文的 rebase or merge?
- 去github上提PR，通知其他人review你的代码
- 按照review建议修改代码并再次提交至远程仓库
git commit
注意 除非特殊情况，此时即使跟master有冲突也不要管，将解决冲突放在review过程结束后（准备merge时）再做
- 如果还有review建议，重复上一步
- merge到master分支
8.1. 如果跟master有冲突，按照Gitlab上的提示解决冲突（参见下文如何解conflict），并再次提交
8.2. 合并到master分支。在Gitlab上的PR页面，点击"Merge pull request"，然后再点击"Delete branch"删除你的branch
关于如何撤销已经commit过的代码
git基础知识
一般在提交代码的时候，顺序是这样的
git status // 查看修改文件状态（已添加至暂存区还是未添加至暂存区）
git add * //将所有修改过的文件报错在暂存区
git commit -m 'xx功能全部完成' // 提交暂存区代码至仓库中
// 在仓库中创建了一个新的提交对象，并且更新了分支以指向这个新的提交对象
git push // 将代码推送至远程仓库
git add 可以看做是 "准备提交"，将修改后的文件保存在暂存区中 ，git commit 可以看做是 "执行提交"，将其暂存区中保存的文件提交到本地仓库；然后git push是将本地仓库中还未推送的更新到远程仓库中
关于git的知识可以到之前的笔记：
https://www.yuque.com/wrwang/fqdmqu/qy7ygq91xgtg2tug#abfb4251
git中reset,revert,restore的使用
学习背景：今天在完成需求进行MR（gitlab中Merege Request)时
我git commit 时候发现多提交了一个配置文件信息，一般来说自己的配置文件是不能上传合并的，所以有了下面知识的学习
reset:撤销 commit
那么在执行完 commit 之后，想撤回 commit，怎么办？
git reset --soft HEAD^
HEAD^ 意思是上一个版本，也可以写成 HEAD~1
如果进行了 2 次 commit ，都想撤回，可以使用 HEAD~2
1. 撤销 commit、不撤销git add .
撤销commit但是对应的文件还是在暂存区中的
soft
git reset --soft HEAD^
2. 撤销 commit、并撤销 git add. 操作、不撤销修改代码
--mixed
git reset --mixed HEAD^
git reset HEAD^
// 效果和 git reset --mixed HEAD^ 一样，--mixed 是默认参数
以上操作将把HEAD指针移动到父提交，但不会改变工作目录中的文件，修改将被保留。
3. 撤销 commit、撤销 git add . 操作、撤销修改代码
hard
git reset --hard HEAD^
- 这个命令将
HEAD指针移动到当前提交的父提交，并且使用--hard选项会使工作目录中的文件恢复到这个父提交的状态； - 这意味着所有自上次提交以来的未提交的修改都将被删除；
- 如果想保留这些修改，可以使用
git stash命令来保存它们，然后在需要的时候再应用这些修改。
顺便提一嘴，如果想要修改 commit 注释，可以执行git commit --amend，此时会进入默认vim 编辑器，修改注释完毕后保存就好了。
reset三种撤销方式小结：
- git reset --soft HEAD^：只撤销本次提交，撤销的文件还在暂存区中的
- git reset --mix HEAD^:撤销本次提交的同时，也将文件从暂存区中撤销，但是工作目录对于文件的修改还在
- git reset --hard HEAD^:撤销本次提交、同时将提交的文件也从暂存区中撤销，同时工作目录修改的内容也撤销（相当于直接回到了上一次提交时拉取代码的状态，即本次新增的代码，修改的内容这些都会被撤销）
revert:撤销
作用
作用：git revert 命令用于撤销一个已存在的提交，但是它会创建一个新的提交来"抵消"掉之前的那个提交所做的所有更改，而不是从版本历史中删除那个提交。这意味着，你可以保留完整的项目历史，同时撤销之前的更改。
如下图所示，我们通过git revert HEAD命令进行撤销
git revert 撤销 某次操作，此次操作之前和之后的commit和history都会保留，并且把这次撤销作为一次最新的提交比这里的C2*,这里的C2*的内容就和C1是一样的了
git revert HEAD #撤销前一次 commit
git revert HEAD^ #撤销前前一次 commit
# git revert commit （比如：fa042ce57ebbe5bb9c8db709f719cec2c58ee7ff）
#撤销指定的版本，撤销也会作为一次提交进行保存。，例如：
git revert fa042ce57ebbe5bb9c8db709f719cec2c58ee7ff #这小指定的这个版本
对于第三个操作怎样找到你想要撤销的提交版本好尼？
使用 git log命令
git log 命令会显示从最近到最远的提交日志。你可以通过添加选项来定制输出。例如：
- 简单地运行
git log会列出所有的提交，每个提交都会显示其哈希值、作者、日期和提交信息。 - 使用
git log --oneline会以更紧凑的方式显示提交日志，每个提交只显示哈希值的前几个字符和提交信息。 - 如果你知道你想要查找的提交的某个关键字（例如，提交信息中的一部分），你可以使用
git log --grep="keyword"来过滤结果。
git revert是提交一个新的版本，将需要revert的版本的内容再反向修改回去，版本会递增，不影响之前提交的内容
结论： 在我们要撤销的提交记录后面居然多了一个新提交！这是因为新提交记录 C2' 引入了更改 ------ 这些更改刚好是用来撤销 C2 这个提交的。也就是说 C2' 的状态与 C1 是相同的。
revert 之后就可以把你的更改推送到远程仓库与别人分享。
参考博客： 原文链接：GIT中reset, restore and revert指令的区别_git restore-CSDN博客
reset和revert异同小结：
小结：
- git revert是用一次新的commit来回滚之前的commit，git reset是直接删除指定的commit。
- 在回滚这一操作上看，效果差不多。但是在日后继续merge以前的老版本时有区别。因为git revert是用一次逆向的commit"中和"之前的提交，因此日后合并老的branch时，导致这部分改变不会再次出现，但是git reset是之间把某些commit在某个branch上删除，因而和老的branch再次merge时，这些被回滚的commit应该还会被引入。
- git reset 是把HEAD向后移动了一下，而git revert是HEAD继续前进，只是新的commit的内容和要revert的内容正好相反，能够抵消要被revert的内容。
以下是AI回答的结果，具有一定参考意义：
git revert 和 git reset 在回滚操作上的确有着本质的区别，这些区别主要体现在它们对Git项目历史的影响上。下面我将详细解释这些区别：
Git Revert
- 操作方式 ：
git revert通过创建一个新的提交（commit）来"撤销"之前的一个或多个提交所做的更改。这个新的提交是之前提交的反向操作，它会在项目历史上留下一条清晰的记录，表明某个更改被撤销了。 - 历史影响 ：由于
git revert是通过添加新的提交来工作的，因此它不会改变现有的项目历史。这意味着其他分支上的更改在将来合并到当前分支时，之前被git revert撤销的更改不会被重新引入，因为那个撤销操作已经成为项目历史的一部分。 - 适用场景 ：
git revert特别适用于需要将更改回滚到某个早期状态，但又不希望丢失这些更改历史的情况。它确保了项目的历史是线性的，易于理解和追踪。
Git Reset
- 操作方式 ：
git reset通过将HEAD指针移动到项目历史中的另一个位置来工作。根据使用的选项（--soft、--mixed、--hard），它还可以选择性地更改索引（staging area）和工作目录（working directory）以匹配新的HEAD位置。 - 历史影响 ：
git reset会改变项目的历史，特别是当使用--hard选项时。然而，需要注意的是，这种改变只会影响本地仓库。如果你已经将更改推送到远程仓库，并且其他人已经基于这些更改进行了工作，那么简单地使用git reset并不会改变远程仓库的历史，也不会影响其他人的工作。但是，如果你之后尝试将更改推送到远程仓库，Git会阻止你这样做，因为这会导致远程仓库和本地仓库之间的历史不一致。 - 适用场景 ：
git reset适用于你还没有将更改推送到远程仓库，或者你确定需要完全撤销一系列提交的情况。但是，由于它会改变项目的历史，因此需要谨慎使用，并确保你了解这种改变的影响。
总结
git revert通过添加新的提交来撤销之前的更改，保留了项目的历史完整性。git reset通过移动HEAD指针来撤销之前的更改，可能会改变项目的历史（特别是当使用--hard选项时）。- 在选择使用哪个命令时，你需要考虑你的具体需求以及你想要如何影响项目的历史。如果你需要保留历史的完整性，那么
git revert是一个更好的选择。如果你需要完全撤销一系列的提交，并且你确信这样做不会影响其他人的工作，那么git reset可能是一个更快捷的选择。但是，请务必谨慎使用git reset，特别是当涉及到已经推送到远程仓库的更改时。
restore：将没加入到暂存区修改的文件还原为之前没修改时的样子
作用：将在工作空间下但是不在暂存区的文件（没有使用add命令）撤销更改(内容恢复到没修改之前的状态）等价于使用git checkout file 命令效果一样，将工作区修改的文件内容撤销掉
git restore --staged <file>：从暂存区中移除文件，但保留工作目录中的更改。git restore <file>：将文件恢复到其最近一次提交时的状态，并丢弃工作目录中的更改。
什么叫工作目录中的修改？
就相当于git restore --staged <file>命令只是将在暂存区中的文件file移除，然后保留工作目录（平常我们使用git管理时的文件夹下所有文件都属于工作目录）下对该文件的修改内容 如果还需要撤销对文件的修改内容那么还需要依靠宇git restore file
小结：工作流程一览
