1
0
wiki/Personal/Journal/2022/W44/2022-11-02.md
2024-08-30 12:29:55 +08:00

2.9 KiB
Raw Permalink Blame History

2022-11-02

Info

Date Weather Moon
周三 19:33 郑州 +16°C ☀️ 🌓

Daily

秋菊堪餐,春兰可佩,留待先生手自栽。 — 沁园春·带湖新居将成·辛弃疾(宋代)

daily_random_picture

Habits

  • 早睡早起 🌃
  • 健康饮食 🥗
  • 多喝热水
  • 保持运动 💪

To-do List

  • 阅读资讯 📺
  • 每日必做
  • 今日读书 📖
  • 今日计划 ✏
  • 今日分享 📌

Notes

郑州因为疫情封禁了一个月了,很烦很烦很烦。特别容易烦躁,每天日复一日的重复性工作我已经烦了,只期待能顺顺利利解封吧。

软考不出意外又很出意外的取消了,这已经是第三次取消了;放了我无数次鸽子了,我已经吐了……。有时间再报名准备吧,来日方长。

最近的学习重心将是成人本科,刷课考试准备学习英语;好烦哦,状态也是一好一坏。先搞成人本科,搞完再说其他的。

周二的时候,更新了一下 Halo 的博客主题,优化了一部分。也遇见了一些问题就是使用 git 进行版本控制如何划定版本。简单思考了一下,大致如下。

此方案主要解决的就是重复性的推送,有时候推送到服务器又发现错了,就很麻烦,故暂时以此解决。如果从开发群体来区分,主要为个人和组织。

  • 个人:容易反反复复的修改和重复性提交,建议以固定日期进行推送和提交(日、周),充分利用工作流和分支模型进行开发,尽量避免重复性提交。热修复则随时随地发布,其他的则固定日期推送提交。
  • 组织:如果是团队协作模式,则由大家约定俗成。如果是领导者模式,则拉到本地以固定的日期进行推送和提交,充分利用工作流和分支模型进行开发。热修复则随时随地的发布。

此方案主要解决的是版本号的划定,有时候刚推送上去就错了,然后还要修复再推送就很容易徒增版本号。如果以结果为导向,主要为路线图和需求。

  • 路线图:开源社区英雄主义,主要是以作品为方式呈现,以产品节点为版本号,每个大版本号都是根据路线图划定的,故不存在太大问题。
  • 需求:建议固定日期,每周或每个月进行版本号的划定。如果以需求完成为版本号界定,则容易出现版本号徒增。

核心主要的思想:坚决执行工作流和分支模型开发模式,固定窗口进行推送和版本号划定,可根据实际情况约定俗成。