在交易的世界里，除了你欺我，我诈你，也还是有真善美。
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 发布上线。
11 年前的今天，我加入了一支新潮的团队。因为当时微信刚出来没多久，那个项目是基于微信搞事的，所以我用“新潮”来形容这个团队。
11 年后，大家都在聊 AI。去年只是起火，今年已经是熊熊大火。一个新时代就摆在眼前。
再看自己一直在折腾的商店项目。去年下半年开始有了相对稳定的用户群，年后日活恢复很快，感受到了商户们渴望赚钱的急切心情。
去年写总结的时候在想：
现在日活保持在 2000 – 3000 之间，如果按照每个季度增长 1000 的速度，到 2024 年底，应该会有 6000 – 7000 的日活。
今天再看上面的图，好像低估了。商户们开年就给出这种铆足劲的开挂状态，可能到年底日活会上万。
不过再怎么说，商店是长尾项目，急也没用，只能耐心迭代。
所以接下去的主要精力会扑在 AI 这个新项目上。有幸结识了一群新朋友。
话说回来，ToB 难免要用到店铺，后续这两个项目也许会有整合机会。
今天 blog 新增一个 Tag，叫“AI之恋”，给自己一个仪式感。
再过 11 年，当我回来看这篇日记的时候，那时会是什么样的心情呢？我也不知道，但应该难免又会稀里哗啦的感慨一顿。
无论如何，享受努力的过程。
昨天去了趟南京，今天兴奋了一天。
忍住了，没发朋友圈。
年前 Nico 说一起搞个 AI 项目。开发团队在南京，年还没过完就订了车票。
今天杭州这边三个人一起去南京，和开发团队见了面，聊聊项目现状。
南京是福地，当年口袋通第一次 outing 去了南京，回来没多久就发达了。
新时代，新世界，新机遇。作为 80 后，可以经历改革开放、互联网、AI 这三个大时代，何其有幸。
代理商的模式是，给一个低价，代理商以较高的价格卖给客户。
但是如果店铺的每一笔订单成交，合作伙伴都可以拿到一笔分润，那合作伙伴就会来劲得多。
以美业合作伙伴为试点，优化了分账流程，跨出了很重要的一步。
年前年后都在搞这个事，适配服务行业的店铺文案。今天完工。
比如订单状态不能叫“待发货”，而应叫“待服务”。
涉及的地方还不少，做成了配置函数，方便维护。
过年是制造深 V 流量的时节。流量回来了，就表示年过完了。
