? Add issue references (e.g. “fix #123”, “re #123”.):
fix #1
git push origin HEAD
git cz是利用了commitizen来替代git commit。详情请点击前端自动化部署的深度实践深入了解。
fix #1用于关闭issue 1。
git push origin HEAD则代表推送到远程仓库同名分支。
创建Merge Request
开发人员发起Merge Request，请求将自己开发的功能特性合入develop分支。
接着Maintainer需要Review代码，确认无误后同意Merge。然后这部分代码就在远程Git仓库入库了，其他开发同学拉取develop分支就能看到了。
issue/2，处理更新日志，版本号等内容，对应issue 2
每个团队的开发节奏都不同，有的团队会每日持续集成发版本提测，有的可能两天一次，这个就不深入讨论了…
那么当我们准备提测时，应该怎么做呢？
通过上节的了解，我们已经知道，迭代内的功能需求都会通过feature/xxx分支合入到develop分支。
提测前，一般来说，还是要更新下CHANGELOG.md和package.json的版本号，可以由Maintainer或其他负责该项事务的同学执行。
主要是执行npm version major/minor/patch -m ‘something done’，具体操作可以参考前端自动化部署的深度实践一文。
git checkout -b issue/2 origin/develop
npm version minor -m ‘迭代1第一次提测’
git push origin HEAD
然后发起merge request合入develop分支
此时，应以最新的develop分支代码在开发环境跑一遍功能，保证版本自测通过。
提测时，由Maintainer发起Merge Request，将develop分支代码合入release分支，此时自动触发Gitlab CI/CD，自动构建并发布至测试环境。
版本提测后，各责任人应在TAPD上将相关需求和缺陷的状态变更为**“测试中”**。
bug/3，一个bug分支，对应issue 3
这里说的是在迭代周期内由测试工程师发现的测试环境中的系统bug，这些bug会被记录在敏捷开发协作平台TAPD上。修复测试环境bug的步骤与开发需求类似，这里简单说下步骤：
- 在Gitlab上创建issue
创建issue，并附上TAPD上的缺陷链接，方便追溯
- 创建分支&修复缺陷
基于develop分支创建分支：
// 3是issue号
git checkout -b bug/3 origin/develop
接着改代码…
- commit & push
PS D:\projects\gitlab\project_xxx> git cz
cz-cli@4.0.3, cz-conventional-changelog@3.1.0
? Select the type of change that you’re committing: fix: A bug fix
? What is the scope of this change (e.g. component or file name): (press enter to skip)
? Write a short, imperative tense description of the change (max 95 chars):
(11) 修复一个测试环境bug
? Provide a longer description of the change: (press enter to skip)
? Are there any breaking changes? No
? Does this change affect any open issues? Yes
? If issues are closed, the commit requires a body. Please enter a longer description of the commit itself:
? Add issue references (e.g. “fix #123”, “re #123”.):
fix #3
git push origin HEAD
- 发起Merge Request
开发人员发起Merge Request，请求将自己修复缺陷引入的代码合入develop分支。
然后Maintainer需要Review代码，同意本次Merge Request。
- 等待回归测试
该bug将在下一次CI/CD后，进入回归测试流程。
- 级别高的测试环境Bug
如果是级别很高的bug，比如影响了系统运行，导致测试人员无法正常测试的，应以release分支为基础创建bug分支，修改完毕后合入release分支，再发起cherry pick合入develop分支。
经过几轮持续集成和回归测试后，一个迭代版本也慢慢趋于稳定，此时也迎来了激动人心的上线时间。我们要做的就是把通过了测试的release分支合入master分支。
这一步相对简单，但是要特别注意权限控制（防止生产环境事故），具体权限控制可以回头看第一章节分支管理。
与release分支类似，master分支自动触发Gitlab CI/CD，自动构建并发布至生产环境。
revert/4，一个回滚分支，对应issue 4
代码升级到线上，但是发现报错，系统无法正常运行。此时如果不能及时排查出问题，那么只能先进行版本回退操作。
先说说惯性思维下，我的版本回退做法。
首先还是创建issue记录下：
基于master分支创建revert/4分支
git checkout -b revert/4 origin/master
假设当前版本是1.1.0，我们想回退到上个版本1.0.3。那么我们需要先查看下1.0.3版本的信息。
PS D:\tusi\projects\gitlab\projectname> git show 1.0.3
commit 90c9170a499c2c5f8f8cf4e97fc49a91d714be50 (tag: 1.0.3, fix/1.0.2_has_bug)
Author: tusi tusi@xxx.com.cn
Date: Thu Feb 20 13:29:31 2020 +0800
fix:1.0.2
diff --git a/README.md b/README.md
index ac831d0…2ee623b 100644
— a/README.md
+++ b/README.md
@@ -10,6 +10,8 @@
只想修改旧版本的bug，不改最新的master
+1.0.2版本还是有个版本，再修复下
特性2提交
特性3提交
主要是取到1.0.3版本对应的commit id，其值为90c9170a499c2c5f8f8cf4e97fc49a91d714be50。
接着，我们根据commit id进行reset操作，再推送到远程同名分支。
git reset --hard 90c9170a499c2c5f8f8cf4e97fc49a91d714be50
git push origin HEAD
接着发起Merge Request把revert/4分支合入master分支。
一般来说，这波操作没什么问题，能解决常规的回滚问题。
临时变通
由于master分支是保护分支，设置了不可push。如果不想通过merge的方式回滚，所以只能先临时设置Maintainer拥有push权限，然后由Maintainer进行回滚操作。
git checkout master
git pull
git show 1.0.3
git reset --hard 90c9170a499c2c5f8f8cf4e97fc49a91d714be50
git push origin HEAD
完事后，还需要记得把master设置为不可push。
Q: 为什么不让
Maintainer一直拥有master的push权限？
A: 主要还是为了防止出现生产环境事故，给予临时性权限更稳妥！
git reset --hard存在什么问题？
如题，git reset --hard确实是存在问题的。git reset --hard属于霸道玩法，直接移动HEAD指针，会丢弃之后的提交记录，如果不慎误操作了也别慌，还是可以通过查询git reflog找到commitId抢救回来的；git reset后还存在一个隐性的问题，如果与旧的branch进行merge操作时，会把git reset回滚的代码重新引入。那么怎么解决这些问题呢？
别慌，这个时候你必须掏出git revert了。
Q:
git revert的优势在哪？
A: 首先，
git revert是通过一次新的commit来进行回滚操作的，HEAD指针向前移动，这样就不会丢失记录；另外，git revert也不会引起merge旧分支时误引入回滚的代码。最重要的是，git revert在回滚的细节控制上更加优秀，可解决部分回滚的需求。
举个栗子，本轮迭代团队共完成需求2项，而上线后发现其中1项需求有致命性缺陷，需要回滚这个需求相关的代码，同时要保留另一个需求的代码。
首先我们查看下日志，找下这两个需求的commitId
PS D:\tusi\projects\test\git_test> git log --oneline
86252da (HEAD -> master, origin/master, origin/HEAD) 解决冲突
e3cef4e (origin/release, release) Merge branch ‘develop’ into ‘release’
f247f38 (origin/develop, develop) 需求2
89502c2 需求1
我们利用git revert回滚需求1相关的代码
git revert -n 89502c2
这时可能要解决冲突，解决完冲突后就可以push到远程master分支了。
git add .
git commit -m ‘回滚需求1的相关代码，并解决冲突’
git push origin master
感觉还是菜菜的，如果大佬们有更优雅的解决方案，求指导啊！
hotfix/5，一个线上热修复分支，对应issue 5
比如线上出现了系统无法登录的bug，测试工程师也在TAPD提交了缺陷记录。那么修复线上bug的步骤是什么呢？
-
创建
issue，标题可以从TAPD中的Bug单中copy过来，而描述就贴上Bug单的链接即可。 -
基于
master分支创建分支hotfix/5。
git checkout -b hotfix/5 origin/master
-
撸代码，修复此bug…
-
修复完此
bug后，提交该分支代码到远程仓库同名分支
git push origin HEAD
- 然后发起
cherry pick合入到master和develop分支，并在master分支打上新的版本tag（假设当前最大的tag是1.0.0，那么新的版本tag应为1.0.1）。
fix/6，一个线上旧版本修复分支，对应issue 6
某些项目产品可能会有多个线上版本同时在运行，那么不可避免要解决旧版本的bug。针对线上旧版本出现的bug，修复步骤与上节类似。
-
创建
issue，描述清楚问题 -
假设当前版本是
1.0.0，而0.9.0版本出了一个bug，应基于tag 0.9.0创建fix分支。
git checkout -b fix/6 0.9.0
- 修复缺陷后，应打上新的
tag 0.9.1，并推送到远程。
git tag 0.9.1
git push origin tag 0.9.1
- 如果此
bug也存在于最新的master分支，则需要git push origin HEAD提交该fix分支代码到远程仓库同名分支，然后发起cherry pick合入到master，此时很大可能存在冲突，需要解决冲突。
在了解到cherry pick之前，我一直认为只有git merge可以合并代码，也好几次遇到合入了不想要的代码的问题。有了cherry pick，我们就可以合并单次提交记录，解决git merge时合并太多不想要的内容的烦恼，在解决bug时特别有用。
经过这段时间的使用，我发现使用git merge合并分支时，会让git log的Graph图看起来有点吃力。
PS D:\tusi\projects\gitlab\projectname> git log --pretty --oneline --graph
- 7f513b0 (HEAD -> develop) Merge branch ‘issue/55’ into ‘release’
|\
| * 1c94437 (origin/issue/55, issue/55) fix: 【bug】XXX1
| * c84edd6 Merge branch ‘release’ of host:project_repository into release
| |\
| |/
|/|
- | 115a26c Merge branch ‘develop’ into ‘release’
|\ \
| * \ 60d7de6 Merge branch ‘issue/30’ into ‘develop’
| |\ \
| | * | 27c59e8 (origin/issue/30, issue/30) fix: 【bug】XXX2
| | | * ea17250 Merge branch ‘release’ of host:project_repository into release
| | | |\
| |||/
|/| | |
- | | | 9fd704b Merge branch ‘develop’ into ‘release’
|\ \ \ \
| |/ / /
| * | | a774d26 Merge branch ‘issue/30’ into ‘develop’
| |\ \ \
| | |/ /
接着我就了解到了git rebase，变基，哈哈哈。由于对rebase了解不深，目前也不敢轻易改用rebase，毕竟rebase还是有很多隐藏的坑的，使用起来要慎重！在这里先挖个坑吧，后面搞懂了再填坑…
=======================================================================
-
一般而言，自己发起的
Merge Request必须由别的同事Review并同意合入，这样更有利于发现代码问题。 -
对了，
TAPD还支持与Gitlab协同的。详情见源码关联指引。
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数前端工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年Web前端开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上前端开发知识点，真正体系化！
由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！
如果你觉得这些内容对你有帮助，可以扫码获取！！（资料价值较高，非无偿）
结尾
正式学习前端大概 3 年多了，很早就想整理这个书单了，因为常常会有朋友问，前端该如何学习，学习前端该看哪些书，我就讲讲我学习的道路中看的一些书，虽然整理的书不多，但是每一本都是那种看一本就秒不绝口的感觉。
以下大部分是我看过的，或者说身边的人推荐的书籍，每一本我都有些相关的推荐语，如果你有看到更好的书欢迎推荐呀。
果低效又漫长，而且极易碰到天花板技术停滞不前！**
因此收集整理了一份《2024年Web前端开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
[外链图片转存中…(img-fXArHQ0D-1711682602678)]
[外链图片转存中…(img-2ZIWamMm-1711682602679)]
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上前端开发知识点，真正体系化！
[外链图片转存中…(img-I8UFInVS-1711682602679)]
由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！
如果你觉得这些内容对你有帮助，可以扫码获取！！（资料价值较高，非无偿）
结尾
正式学习前端大概 3 年多了，很早就想整理这个书单了，因为常常会有朋友问，前端该如何学习，学习前端该看哪些书，我就讲讲我学习的道路中看的一些书，虽然整理的书不多，但是每一本都是那种看一本就秒不绝口的感觉。
以下大部分是我看过的，或者说身边的人推荐的书籍，每一本我都有些相关的推荐语，如果你有看到更好的书欢迎推荐呀。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
