在交易的世界里,除了你欺我,我诈你,也还是有真善美。
Archives for :
写了一份 Git 工作流规范,方便团队协作。
基础分支(不要直接在这两个分支上开发)
- develop (开发环境)
- master (生产环境,主分支)
工作流基础
- feature (开发分支,从 develop 拉取)
- release (预发布分支,从 develop 拉取)
- hotfix (补丁分支,从 master 拉取)
- merge (合并分支)
第一部分:开发
创建个人开发分支
- 开始新功能开发时,每个人都基于 develop 创建一个新的 feature 分支,这个 feature 不会影响他人。
- 每天提交代码到自己的 feature,避免本地代码意外丢失。
同事之间同步代码
- 每天都把 develop 分支 merge 到你的分支。如果长时间没有进行这项操作,那么将来 merge 分支时很可能会有大量代码冲突。
- 如果确认你分支的代码已经可以正常运行,记得把你的分支 merge 到 develop。
- 如果有需要,同事之间也可以互相 merge 分支,你 merge 我的,我 merge 你的。
解决代码冲突(这个很重要)
- 如果 merge 分支时发生代码冲突,一定要找冲突方确认。
- 群里截图问一下这段代码是谁的,双方确认后手动解决,避免误删同事代码。
第二部分:测试
- 所有人把自己的分支合并到 develop 分支,将 develop 代码提交到测试环境进行测试。
- 如果有 bug,大家仍然在自己的分支中修改,修改完后再 merge 到 develop 分支。
第三部分:预发布
- 所有人把自己的分支合并到 develop 分支,由专人从 develop 拉 release 分支,进行发布前的最后测试。
- 此时应该没有大的问题,如果有问题,大家可直接在 release 分支修改。
第四部分:发布
- release 分支确认最终测试通过后,由专人将 release 合并到 develop 和 master 分支,将 master 发布上线。
- 到这一步后,此前参与开发的所有分支都不要再使用,可以删除本地分支。新的功能拉取新的 feature 进行开发。
第五部分:bug修复
- 如果需要修复线上 bug,从 master 拉取 hotfix 分支,修复完成后合并到 develop 和 master 分支,将 master 发布上线。
信息已经爆炸,哪都是 AI。
整整一个月没运动了。这周恢复。
春节前那次生病应该是二阳,要不就是其他流感,反正一家人前后都中招。又是一个在喉咙痛中过完的年。
昨天爬楼本来以为两趟就差不多了,结果两趟爬完汗都没怎么出,再爬一趟。
11 年前的今天,我加入了一支新潮的团队。因为当时微信刚出来没多久,那个项目是基于微信搞事的,所以我用“新潮”来形容这个团队。
11 年后,大家都在聊 AI。去年只是起火,今年已经是熊熊大火。一个新时代就摆在眼前。
再看自己一直在折腾的商店项目。去年下半年开始有了相对稳定的用户群,年后日活恢复很快,感受到了商户们渴望赚钱的急切心情。
去年写总结的时候在想:
现在日活保持在 2000 – 3000 之间,如果按照每个季度增长 1000 的速度,到 2024 年底,应该会有 6000 – 7000 的日活。
今天再看上面的图,好像低估了。商户们开年就给出这种铆足劲的开挂状态,可能到年底日活会上万。
不过再怎么说,商店是长尾项目,急也没用,只能耐心迭代。
所以接下去的主要精力会扑在 AI 这个新项目上。有幸结识了一群新朋友。
话说回来,ToB 难免要用到店铺,后续这两个项目也许会有整合机会。
今天 blog 新增一个 Tag,叫“AI之恋”,给自己一个仪式感。
再过 11 年,当我回来看这篇日记的时候,那时会是什么样的心情呢?我也不知道,但应该难免又会稀里哗啦的感慨一顿。
无论如何,享受努力的过程。
娃说:“好烦啊,我们组六个人,就我一个没戴眼镜的。”
我不解,问为啥烦?
答:“因为他们语文都比我好啊。”
呃(¯―¯٥) 那确实挺烦的。