AllSaints-实习工作文档
本文最后更新于 2024-04-26，文章内容可能已经过时。
AllSaints-实习工作文档
本文档为2023寒假在深圳万声科技文化公司实习记录。有两个目的：
1.记录实习工作，与学习的知识
2.为以后的实习和工作文档的撰写积累模版
非常优秀的公司，实习体验非常好。
1.各种账号：
各种信息已经删除，仅做记录之用。
1.1 阿里邮箱
格式：
访问地址
账号
密码
如无特殊说明，下文一样
1.2 JIRA
1.3 Mantis：
1.4 国内 开源堡垒机：
Redis测试环境 redis-cli -h 地址 -p 6379 -c
2.工作流程：
2.1 使用跳板机debug：
使用jump server海外跳板机进行操作
进入之后 使用kubectl 命令进入pod
kubectl get pods
kubectl logs -f allmusic-api-ktv-0 查看日志
redis-cli -h 地址 -p 6379 -c
进入redis
redis-cli -h 地址 -p 6379 -c
debug
国内测试环境 用开源堡垒机
找test zhy as golang 进入backup
tail -f api.log | grep mocktest 使用这种命令进行日志过滤输出 不需要加引号
连接redis：
redis-cli -h 地址 -p 6379 -c
查找key get
删除key del
不需要加引号
2.2 开发环境选择：
2.2.1 ktv项目：
海外测试 ktv
环境用test
Vpn 用dev-sin
meta pkg 用oversea_release
2.3 vpn：
2.4 代码提交：
提交代码 一定要注意是否新的文件 否则有可能编译不通过！！！！！！！！！ 太愚蠢了
2.5 新接口开发：
1.收到jira单
2.看需求
3.找到上下游是谁负责
4.找到分支 建立属于自己的新分支 具体需求 ）如10.15.20之类的 可以从jira上找
5.分支切换 具体以来的分支可以看：
访问地址
6.选择路由开发
看业务 不知道的直接找人问
7.开发
2.6 海外线上环境debug：
1.在oversea_live_dev上修复bug并验证。
2.修复后 分别从oversea_master和oversea_release分别拉一个分支，修改后提交。
3.oversea_live_dev只是提供了一个开发与测试环境，与任何一个正式环境都不同。
3.业务点：
3.1 业务kid维护
业务 ktv 用户kid逻辑维
全局id生成 kid
分布式锁加定时任务 定时生成五万条id存进redis
先生成id储存起来
使用的时候去取
KsongConfigSwitch
3.2 代码改造方案：
全链路mock方案
对测试和对接人员进行缓存屏蔽
整体方案
访问地址
api方案
1.代理 使用ctx选定代理的实现 暂时采用 2.拦截编译
理论参考 https://www.anquanke.com/post/id/258431
项目 https://github.com/apache/skywalking-go
3.go依赖注入：
修改源代码的方式
代码生成的方式
wire https://github.com/google/wire
3.3 init改造：
golang init函数
3.4 暗词优化
3.5 会员中心歌曲下发
3.6 臻享会员栏目内容：
和cms疯狂讨论
工作流程有问题
4.其他知识：
4.1 git：
1.git rebase
2.Git底层逻辑
三个分区与两种冲突：拉取时发生or上传时发生
3.手写一个git 只在远程仓库保留分支的概念
4.在被git管理的文件中 红色的是未被管理的 蓝色的是有修改未提交的 白色的是同步的
5.git pull --rebase
https://blog.csdn.net/yao_hou/article/details/108178717
6.第一次使用git的http进行clone时，需要输入用户名和密码。
第一次输入正确后，后续就不需要再次输入。
7.git fetch --prune
这个命令会将远程仓库的引用信息更新到本地，并删除本地不存在的远程引用。这样就可以解决由于引用冲突而导致的更新问题。
8.git reset --hard HEAD
撤销当前工作目录下的所有修改并恢复到最近一次提交的状态.
9.git remote prune origin 命令用于清理远程仓库中不存在的引用.
出现quit 直接enter。
10.检查&删除分支：
# 检查是否存在名为 'wpy/oversea_master' 的分支
git branch --list 'wpy/oversea_master'
# 如果存在，删除该分支（谨慎操作，确保分支内容已经备份或者不再需要）
git branch -d 'wpy/oversea_master'11.重命名分支：
git branch -m 'wpy/oversea_master 2/addlanguageconsumer'new_branch_name12.报错：
wpy@wpydeMacBook-Pro allmusic-api-ktv % git reset --hard
致命错误：无法创建 '/Users/wpy/Desktop/桌面/projects/GOPATH/AllSaints/allmusic-api-ktv/.git/index.lock'：File exists。
似乎另外一个 git 进程在这个仓库中运行，例如：'git commit' 命令打
开了一个编辑器。请确认所有进程都已经关闭然后重试。如果仍然报错，
可能之前有一个 git 进程在这个仓库中异常退出：
手动删除这个文件再继续。这个错误说明 Git 无法创建索引文件锁（index.lock），因为该文件已经存在。索引文件锁用于防止多个 Git 进程同时修改仓库的索引文件，避免数据损坏。
通常情况下，这种情况发生是因为有另一个 Git 进程正在运行或异常退出导致索引文件锁没有正确释放。
关闭其他 Git 进程: 确保您当前计算机上没有其他 Git 进程在运行。检查是否有其他终端窗口或编辑器中正在进行的 Git 操作，并将其关闭。
删除索引文件锁: 如果确认没有其他 Git 进程在运行，您可以手动删除索引文件锁。使用以下命令在终端中执行：
bashCopy code rm /Users/wpy/Desktop/桌面/projects/GOPATH/AllSaints/allmusic-api-ktv/.git/index.lock重试操作: 删除索引文件锁后，您可以再次尝试执行之前的 Git 命令，如
git reset --hard。
12.git merge：
git merge <branch_name>这将把 <branch_name> 分支的更改合并到当前所在的分支中。
Git 首先确定待合并分支和当前分支的共同祖先。这个共同祖先是两个分支最后一次分叉（commit point）的基准点。
当前分支和待合并分支在共同祖先之后的变更。它会识别出这些变更，并尝试将它们应用到当前分支上。如果没有冲突，合并将会自动进行。
可以从一个文件的角度去理解，毕竟这些操作都是以每个文件为基本单位的。
对这个文件而言，它有很多的提交，而两个分支上有这个文件不同的样子，也就是不同的提交。merge时会寻找他们的共同祖先，也就是共同的提交，然后还是应用特性。
13.git rebase:
变基。
git rebase <branch_name> 对git merge来说 就是产生了一个新提交 用来修改代码 比较好理解
而git rebase 就是先找到两个分支的共同祖先然后：
1.取消掉当前分支的从祖先提交到最新提交的所有commit.
2.把上面的操作临时保存成 patch 文件，存在 .git/rebase 目录下.
3.把rebase后面的分支的提交应用到当前分支上.
4.把上面保存的 patch 文件应用到 feature1 分支上.
在rebase中也会出现冲突，与merge一样的，也需要手动解决。
本质上rebase和merge的区别就是修改了提交的顺序，而代码理论上是没有区别的。
所谓变基，就是改变了当前分支的基础分支。
假设我从master上的commit1拉下来代码开始开发，然后过了一段时间后，master已经到了commit3.而我自己的本地也有commit，此时我可以在本地commit之后直接merge master分支，也可以直接rebase，这样就相当于是我从master的commit3开始开发了，我开发的基础通过rebase命令从commit1改变成了commit3.
优点：
git rebase可以在当前分支上产生线性的提交记录。提供整洁的提交历史。
缺点：
git rebase会修改当前分支上提交的记录。
使用场景：
1.拉公共分支最新代码——rebase，也就是git pull -r或git pull --rebase。这样的好处很明显，提交记录会比较简洁。但有个缺点就是rebase以后我就不知道我的当前分支最早是从哪个分支拉出来的了，因为基底变了嘛，所以看个人需求了。总体来说，即使是单机也不建议使用。 2.往公共分支上合代码——merge。如果使用rebase，那么其他开发人员想看主分支的历史，就不是原来的历史了，历史已经被你篡改了。举个例子解释下，比如张三和李四从共同的节点拉出来开发，张三先开发完提交了两次然后merge上去了，李四后来开发完如果rebase上去（注意，李四需要切换到自己本地的主分支，假设先pull了张三的最新改动下来，然后执行<git rebase 李四的开发分支>，然后再git push到远端），则李四的新提交变成了张三的新提交的新基底，本来李四的提交是最新的，结果最新的提交显示反而是张三的，就乱套了，以后有问题就不好追溯了。 3.正因如此，大部分公司其实会禁用rebase，不管是拉代码还是push代码统一都使用merge，虽然会多出无意义的一条提交记录“Merge … to …”，但至少能清楚地知道主线上谁合了的代码以及他们合代码的时间先后顺序。
而git pull --rebase就是git fetch和git rebase,就像 git pull是git fetch和git merge一样。
还有一个应用：把本地的多个commit变成同一个：
通过 git rebase 将多个提交变成同一个可以使用交互式 rebase 的方式。这允许你在重新应用提交的过程中对提交进行编辑，包括合并多个提交为一个。
下面是一个简单的步骤：
在你的分支上执行交互式 rebase：
cssCopy code git rebase -i HEAD~n其中，
n是你想要将提交合并的提交数量。这会打开一个交互式界面，列出了你要 rebase 的提交列表。它会类似于：
sqlCopy code pick 1234567 Commit message 1 pick 2345678 Commit message 2 pick 3456789 Commit message 3在这个界面中，将你想要合并的提交的前面标记为
squash或s，或者简写为s。这告诉 Git 将这个提交与前一个提交合并。sqlCopy code pick 1234567 Commit message 1 squash 2345678 Commit message 2 squash 3456789 Commit message 3保存并关闭编辑器。Git 将会合并你标记为
squash的提交。如果有必要，Git 会打开一个编辑器供你编辑合并后的提交信息。你可以保留其中一个提交的信息，或者编辑为新的提交信息。
保存并关闭编辑器，Git 会应用你的编辑并完成 rebase 过程。
请注意，在进行交互式 rebase 时一定要小心，确保你不会丢失重要的提交或者改变了提交历史。
但是其实这个也没什么用 因为总要有git merge的过程 而无论如何 git merge会产生，且只会产生一个commit 所以没什么影响。
究极总结：
git rebase基本没用 线上完全不能使用 本地要不要用全看心情。没什么必要。
4.2 charles：
解析http请求。
4.3 go语言相关：
1.defer panic
2.context:
context使用
初始化 ctx, _ := context.WithCancel(context.Background())
set ctx = context.WithValue(ctx, "test", "1")
get ctx.Value("test") == "1"
3.Struct 里面带有interface
4.4 反射应用：实现异常处理：
用反射实现异常处理 实现类似try-catch的方法
//调用业务逻辑获取两个返回值
res, err := ktvuserservice.EditKTVUser(kid, userName, nickName, intro, province, city, utils.GetDeviceClientIp(), cast.ToInt(gender), birthday, coverBytes, headerInfo, userType, internal)
//处理异常，规范写法
if err != nil {
• if reflect.DeepEqual(err, errors3.New(e.*UserNicknameInvalid*)) {
• base.ResponseUserNicknameInvalid(c)
• } else if reflect.DeepEqual(err, errors3.New(e.*KTVUserDescIllegal*)) {
• base.ResponseKTVUserDescIllegal(c)
• } else if reflect.DeepEqual(err, errors3.New(e.*KTVUserNickNameIllegal*)) {
• base.ResponseKTVUserNickNameIllegal(c)
• } else if reflect.DeepEqual(err, errors3.New(e.*UserImageIllegal*)) {
• base.ResponseUserImageIllegal(c)
• } else if reflect.DeepEqual(err, errors3.New(e.*KTVEditRoomNotAllow*)) {
• base.ResponseKTVEditRoomNotAllow(c)
• } else if reflect.DeepEqual(err, errors3.New(e.*EditingProfileNotAllow*)) {
• base.ResponseEditingProfileNotAllow(c)
• } else {
• base.HandlerError(c, err)
• }
} else {
• base.ResponseSuc(c, res)
}4.5 linux相关：
1.在Linux中，pwd命令用于显示当前工作目录的路径。无需任何参数，它会将完整路径名打印到标准输出。
2.
cat 文件名 显示文件内容
3.
open . 打开当前文件夹
4.
cd 返回最高层
cd .. 返回上一级文件夹
curl命令
curl --location --request GET 'http://10.171.1.1:9050/api/v2/actor/mocktest?version=10.12.0&buildVersion=40.10.12.0dev_bde5704_230815&ak=test&nonce=0d65f19827e146f1bed34c93a56f3f5c&ts=1694063364267&uid=o_id_HoGMnrpSEsUyRHqKKk7xtL&utoken=dba3e2766062448b96c1bd33dca36aa8&sign=2c51e92468ceb600339e8c0c32ed60b746f7fb18&actorId=1808' \
--header 'dev-build-version: 40.10.12.0dev_bde5704_230815' \
--header 'dev-brand: OPPO' \
--header 'dev-manufacturer: OPPO' \
--header 'dev-model: oppo R11' \
--header 'dev-language: zh_cn' \
--header 'dev-region: cn' \
--header 'dev-timezone: Asia/Shanghai' \
--header 'dev-app-version: 101012000' \
--header 'dev-channel: 1001' \
--header 'dev-package: com.heytap.music' \
--header 'dev-id: d41d8cd98f00b204e9800998ecf8427e' \
--header 'dev-pid: 0d814e5556bb4f5083e781442986e867' \
--header 'dev-ab-experiment: BSlZPEgUlwFA4BLhvKasXgbRmHQXPxZogjxbFX9Yhlk=' \
--header 'dev-distinct-id: c3d952b4-2885-4ebe-89e8-032efa2ae707' \
--header 'dev-android-release-version: 6.0.1' \
--header 'dev-android-version: 23' \
--header 'dev-net: WIFI' \
--header 'dev-ou-id;' \
--header 'dev-du-id;' \
--header 'dev-utoken-pass: 1' \
--header 'sign-pass: 1' \
--header 'testId: 1' \
--header 'dev-mock: 1' \
--header 'User-Agent: Apifox/1.0.0 (https://apifox.com)' \
--header 'Accept: */*' \
--header 'Host: 10.171.1.1:9050' \
--header 'Connection: keep-alive'用来访问接口
6.ll与ls：
ls 是最基本的列出目录内容的命令。
ll 实际上是 ls -l 命令的别名或缩写。ll 是一种更为人们友好的列出目录内容的方式。
ll 命令会以长格式列出目录内容，包括文件和目录的权限、所有者、大小、修改日期等信息。
使用 ll 命令可以更直观地查看文件和目录的详细信息，而不需要额外地键入 -l 选项。
总的来说，ll 可以看作是 ls -l 的一种简化形式，提供了更为详细的目录内容信息，更适合用户查看和分析。
7.cd /
进入根目录
8.grep 用来进行各种过滤
cat * | grep "panic"
4.6 学习网站
1.地鼠文档
http://www.topgoer.cn
2.知识星球https://www.golangroadmap.com/
3.极客兔兔
https://geektutu.com/post/hpg-reflect.html
4.go语言项目推荐 知乎文章
https://www.zhihu.com/question/20801814
5.go语言官网
https://go.dev/ref/mem
6.阿秀的学习笔记
https://interviewguide.cn/notes/01-guide/web-guide-reading.html
7.go语言专家教程
https://rainbowmango.gitbook.io/go/di-yi-zhang-chang-jian-shu-ju-jie-gou-shi-xian-yuan-li/1.2-slice
8.go程序员面试宝典
https://golang.design/go-questions/slice/grow/
9.golang修养之路 https://www.yuque.com/aceld/golang/zhzanb#d22d33ae
10.？？？
https://www.incredibuild.cn/free-trial?utm_source=baidusem&utm_medium=cpc&utm_campaign=mkto_2365&utm_content=build_acceleration&utm_term=联合编译工具&bd_vid=7456271016110675534
4.7 其他知识和网站：
1.ide中 代码行的左边 右键单击 可以使用git追溯注解 可以看到代码是谁写的
2.https://mp.weixin.qq.com/s__biz=MzI2NDU4OTExOQ==&mid=2247657137&idx=1&sn=aaf08c399ee70dd5deb33b083da9f038&chksm=eaa67ce1ddd1f5f7c722a5c7fb66abc690629387dd57825a54405ccd9a9ed8501ede3ddc2aa2&scene=21#wechat_redirect
3.cdn：
内容分发网络。
可以理解为跟oss一样的服务，用户上传自己的静态页面，通过这个服务，把页面部署到全国各地的各个地方去。
https://blog.csdn.net/u012060033/article/details/125065781?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522170851252416800186567158%2522%252C%2522scm%2522%253A%252220140713.130102334..%2522%257D&request_id=170851252416800186567158&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~all~top_positive~default-1-125065781-null-null.142^v99^pc_search_result_base8&utm_term=cdn&spm=1018.2226.3001.4187
4.8 开发流程：
研究起因：
在修复bug时 发现master release差异不同以及其他问题。
https://juejin.cn/post/6967981728619544606#heading-4
一个项目至少会包含开发环境，测试环境，生产环境三个环境，这是一个项目标准的开发生命周期。开发团队如何管理项目的开发生命周期就会直接影响到开发的效率以及产品的质量。在业界大部分团队都会使用版本管理工具来进行管理，开源使用最多的如 github 等，在这种主流的版本管理工具中，分支是作为一个基石的存在，所有的管理功能几乎都是围绕分支来建设的，所以一个好的，符合团队特性的分支开发模式，是可以大大减少开发人员之间不必要的沟通协作成本，显著提升软件的开发、集成和发布效率。
4.8.1 特性分支开发模式：
特性分支开发模式是指为一个或多个特定的需求 / 缺陷 / 任务，从主干分支上拉出特性代码分支（branch），在其特性代码分支上完成相应的开发（一般会经过增量测试）后，再把它合并（merge）到主干分支准备发布的开发模式。
一般特性分支开发模式中常用的有三种：Git-Flow 模式，Github-Flow 模式和Gitlab-Flow 模式。
优势：
分工协作规则明确。整个开发周期中的各个步骤基本都有对应的分支，对于开发人员只需要遵循规则，在对应分支上进行对应的开发工作即可。
特性开发周期相对宽松。因为特性分支是有对应的开发者负责，所以对于一些较大较复杂的特性可以在特性分支上开发完成后再合入主干。
特性测试相对友好。特性功能的测试在特性开发分支关闭前都可以进行，这给测试预留了较多时间，对测试的能力要求也相对宽松，很多时候都可以进行手工测试。
劣势：
分支管理复杂。因为特性分支开发的基础就是多个分支协作，所以必然会创建很多不同的特性开发分支和特性基线分支，如果有些分支在生命周期结束后开发人员没有及时进行销毁，时间一长，必然会造成无效分支冗余，管理成本将会越来越高。
学习成本高。因为特性分支开发模式中不同的分支有不同的功能，代码在分支上的流转也需要遵循一定的规则，且不同的团队的规则也会不同，这样对于开发人员的学习成本很高，且因为分支较多，在代码的流转过程中也会增加出错的几率。
合并冲突多，迭代速度慢。因为特性的开发都是要在整个特性开发完成结束后才合并到主干分支上，这就意味着特性分支与主干分支一定会存在较多差异，并且特性分支的生命周期越长，与主干的代码差异越大，合并冲突也越多，解决冲突相应的时间和人力成本也会越高。同理迭代速度也会越慢。
需要较多的测试环境。每个特性分支的测试都至少需要准备一个测试环境，且在该特性通过测试前会一直占用，所以并行的特性开发数量会受到限制。
4.8.1.1 Git-Flow 模式：
标准的 Git-Flow 模式一般会包含以下几种分支：
feature 分支：开发者进行对应功能开发的开发分支。
develop 分支：对开发者开发的功能进行集成的分支。
release 分支：负责版本发布的分支。
hotfix 分支：对线上 bug 进行热修复分支。
master 分支：最新线上代码的基准分支。
本地开发：
拉取功能分支，开发，开发完成之后测试通过后上传到develop.
发布：
在develop上进行全测试 测试后合并到master 然后从master拉取release进行发布。
线上debug：
当新版本已发布 release 分支代码与 master 上的代码同步时，一般会从 master 分支上拉出 hotfix 的分支，专门用于热修复，修复完成之后，进行测试通过，将 hotfix 代码集成到 develop 分支上，再从 develop 分支拉出新的 release 分支上进行发布，同时也需要将 hotfix 代码同步到 master 分支上，保证主干分支代码的标准性。
若是 release 分支代码未发布时，出现 bug 需要热修复，则可以直接在 release 分支上进行修复，进行测试通过后，将修复后的 release 分支代码同步到 develop 分支上，release 分支依然按预期发布，发布的同时 develop 分支同步到 master 分支上。
Git-Flow 模式可以根据不同场景，不同需求提供相当完备的各种分支组合，基本能适应各类团队开发场景，以至于很长一段时间，人们都认为这就是教科书级的 Git 分支使用方式。但是随着普及的范围扩大，人们也发现了这种模式的一些弊端：
分支特别多，每个分支都有自己的职责，各种组合切换非常复杂，上手成本和管理成本非常高。
合并冲突，feature 分支都需要向 develop 分支合并，如果 feature 分支生命周期很长，就意味着它与 develop 分支的代码差异越大，冲突概率和解决冲突的难度也越高。主干分支同理，如果同时几个长生命周期的 feature 分支向 develop 合并，将是集成的噩梦。
需要较多环境资源，毕竟一个 feature 分支就需要一个测试环境资源，且在开发完成前会一直占用。
4.8.1.2 GitHub-Flow 模式：
GitHub-Flow 模式相较于 Git-Flow 模式更为简洁，没有了 Git-Flow 模式中 develop ， hoxfix 和 release 分支，对于 GitHub-Flow 模式来说，发布版本应该是持续的，快速的。feature 分支即 develop 分支，master 分支即 release 分支，对于 hotfix 的处理，GitHub-Flow 模式认为本质上也是特性修改，处理方式和 feature 分支理念是一致的。
总的来说，所有特性修改都能快速集成到 master 上发布，小步快走，快速迭代。
GitHub-Flow 模式在特性分支开发模式中最为简洁，持续集成部署的效率最高。因为所有特性修改的内容会频繁的合入 master 中，并频繁进行部署，这意味着可以最小粒度部署特性修改的代码，在当前倡导持续快速交付的环境下，显然这种模式具有很大的优势。
但因为没有 release 分支的存在，需要建立完善的 rollback 机制来保障线上服务问题后的快速恢复。
4.8.1.3 GitLab-Flow 模式：
GitLab-Flow 模式相较于上两种模式，提供了一种比较中和的选择，既不像 GitHub-Flow 模式简单，也不像 Git-Flow 模式臃肿。
当一个特性功能在 Feature 分支上开发完成后，提交 merge request 将代码合并到 master 分支上，部署到集成环境上进行验证。
当验证通过后，从集成环境的这个节点，拉出预发布环境 pre-production 分支进行预发环境的服务部署。
按照相同的方式将 pre-production 分支上的代码合并到 production 分支上就可以进行生产环境的部署了。 
4.8.2 主干开发模式：
主干开发模式是指所有的开发人员仅在一个主干分支（master）上进行协作开发，一般不允许新建其他长期存在的开发分支，所有的代码提交均需要在主干分支上完成。
通常这种开发模式下，开发者需要有较高频率的代码推送行为，一般一天至少提交一次，当主干分支达到发布条件后，就从主干分支上拉出发布分支（release）进行版本发布。
开发或测试过程中发现的代码缺陷也会直接在主干上进行修复，再根据实际需求 cherry pick 到特定的发布分支或是进行新版本发布。
优势：
分支简洁，实践简单，分支管理成本低。
开发人员易上手，过程出错率低。
合并冲突少，解决冲突成本低。
版本迭代速度快，更符合持续集成和持续交付的理念。
劣势：
对团队的基础架构和协作能力的要求很高。若合入主干的代码质量出现问题将会阻塞整个团队的进度，所以一方面需要团队成员的个人能力和协作能力比较强；另一方面需要完善的持续集成能力的基础平台，提供回滚等快速解决问题的能力。
对团队代码质量要求高，评审机制要求完善。需要有完善的 CR 机制，将问题代码尽可能在发布的前置环节发现并解决。
自动化测试能力要求非常高。需要完善的冒烟和单元测试，确保每次合入主干的代码的正确性。因为主干模式合入代码的频率很高，所以人工测试肯定是无法保证及时响应测试需求，一定需要自动化测试。
需要有特性隔离方案。主干开发模式中因为特性功能需要拆分成很小的粒度，有时候特性功能需要相互依赖，但相互依赖的特性又无法保证同一时间上线，就十分有可能出现半成品特性功能，这时候就需要采用特性隔离方案将这些半成品特性进行隔离。
4.8.3 公司开发模式：
4.8.3.1 文档里写的：
分支构成
product_xx，product，master，dev
product_xx 分支：历史生产环境版本的稳定分支，非解决bug禁止提交 使用tag进行对版本管理
product 分支：当前生产环境版本分支，每次版本合并时打上对应版本tag标签，非必要不允许直接提交。
master 分支：当前生产环境版本分支的灰度分支，具备最新可上生产的代码。
feature-x分支：当前版本新功能分支，开发完成后发merge request到【develop-版本分分支】，通过后自行合并至【dev】。
develop-版本分支: 当前开发功能版本的分支，版本完成后统一合并至【master】进行版本灰度。
dev 分支：当前开发版本分支，每次版本迭代合并至master分支前会打上对应版本tag标签，不再直接提交功能代码至此分支，可在该分之提交debug日志或者一些hard code返回信息供客户端使用，接收【develop-版本分支】分支合并或者【product】分出来【hotfix-xxx】分支。
test分支：测试分支，只接收【develop-版本分支】和【hotfix-xxx】分支的merge request
在文档的要求下 开发的流程应该是这样的：
1.从product拉取develop分支
2.从develop分支拉取feature分支
3.在feature分支上开发
4.开发完成后，发mr到develop分支
5.develop分支合并到test进行测试
6.通过后合并到master
7.master测试 通过后合并到product。
4.8.3.2 实际上的：
1.从product拉取develop分支
2.从develop分支拉取feature分支
3.在feature分支上开发
4.开发完成后，从feature分支向test分支发mr 进行cr和测试
5.通过后 发mr到develop分支
6.develop合并到master
7.master测试 通过后合并到product。
8.线上bug修复 从线上环境拉分支，然后提mr到测试环境 没有问题后发mr到线上环境。
可以得出结论 现在这个情况上有问题的：
1.文档没有更新
2.从develop上面拉下来的分支 却要向一个没有前置分支的test分支合并 肯定会出现问题
3.feature分支无法测试 没有向test分支发mr的依据根据前文可以得出结论 现在的情况是不具备git-flow的条件的情况下（测试环境达不到要求，只有一个测试环境，而develop是没有测试环境的），使用了git-flow模式。从而会出现各种问题。
解决方案：
既然测试环境满足不了git-flow模式的要求 那么考虑使用有限的环境 修改模式。
最合适的是gitlab-flow模式.
假设我们把test的环境部署给到每次的develop，开发人员开发完成后发送mr到develop
cr后合并进入develop 然后使用jenkins进行cd 对接人员和测试人员都在develop上进行操作,没有问题后合并develop。
4.8.3.3 和leader讨论后的：
国内的开发模式和文档里写的相同。
1.开出develop分支 并merge into dev，merge into test 手动解决冲突。
2.从develop开出feature
3.fearture开发完成后，发mr到develop，然后通过后合并到dev。
4.dev有部署的环境。可以在此环境与前端联调。
5.dev联调完成后，develop发mr到test。测试人员主要在test进行测试。
6.测试完成后，发上线申请，develop合并到master，product。
7.开出release进行部署。
在这种情况下可以解决上文的不分相关问题。但是feature分支仍然无法测试。修改成github-flow仍有意义。
5.当前工作：
2.实习工作总结
1.mock加内存数据库相关 压测
2.业务相关 ktv 多人pk 每日推荐歌曲 mq client底层
3.公司架构 业务流程总结
1.复杂结构体转换 java-go在定义好的结构体基础上转换 中间语言 网站的形式
2.业务 会员栏目配置 直接返回全部数组还是分开做
