2022-11-02
Info
Date | Weather | Moon |
---|---|---|
周三 19:33 | 郑州 +16°C ☀️ | 🌓 |
Daily
秋菊堪餐,春兰可佩,留待先生手自栽。 — 沁园春·带湖新居将成·辛弃疾(宋代)
Habits
- 早睡早起 🌃
- 健康饮食 🥗
- 多喝热水 ☕️
- 保持运动 💪
To-do List
- 阅读资讯 📺
- 每日必做 ✨
- 今日读书 📖
- 今日计划 ✏
- 今日分享 📌
Notes
郑州因为疫情封禁了一个月了,很烦很烦很烦。特别容易烦躁,每天日复一日的重复性工作我已经烦了,只期待能顺顺利利解封吧。
软考不出意外又很出意外的取消了,这已经是第三次取消了;放了我无数次鸽子了,我已经吐了……。有时间再报名准备吧,来日方长。
最近的学习重心将是成人本科,刷课考试准备学习英语;好烦哦,状态也是一好一坏。先搞成人本科,搞完再说其他的。
周二的时候,更新了一下 Halo 的博客主题,优化了一部分。也遇见了一些问题就是使用 git 进行版本控制如何划定版本。简单思考了一下,大致如下。
此方案主要解决的就是重复性的推送,有时候推送到服务器又发现错了,就很麻烦,故暂时以此解决。如果从开发群体来区分,主要为个人和组织。
- 个人:容易反反复复的修改和重复性提交,建议以固定日期进行推送和提交(日、周),充分利用工作流和分支模型进行开发,尽量避免重复性提交。热修复则随时随地发布,其他的则固定日期推送提交。
- 组织:如果是团队协作模式,则由大家约定俗成。如果是领导者模式,则拉到本地以固定的日期进行推送和提交,充分利用工作流和分支模型进行开发。热修复则随时随地的发布。
此方案主要解决的是版本号的划定,有时候刚推送上去就错了,然后还要修复再推送就很容易徒增版本号。如果以结果为导向,主要为路线图和需求。
- 路线图:开源社区英雄主义,主要是以作品为方式呈现,以产品节点为版本号,每个大版本号都是根据路线图划定的,故不存在太大问题。
- 需求:建议固定日期,每周或每个月进行版本号的划定。如果以需求完成为版本号界定,则容易出现版本号徒增。
核心主要的思想:坚决执行工作流和分支模型开发模式,固定窗口进行推送和版本号划定,可根据实际情况约定俗成。