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