有没有关于如何为你在业余时间开发的仅供娱乐但将被某些人使用的软件进行版本控制的指南或标准最佳实践?我认为有必要对这种软件进行版本控制,以便您知道正在谈论的版本(例如用于修复错误、支持等)。
但是我应该从哪里开始进行版本控制呢?0.0.0?还是0.0?然后我该如何增加这些数字?主要版本.次要更改?每次提交到版本控制系统都应该是另一个版本吗?还是只针对在生产环境中使用的版本?
有没有关于如何为你在业余时间开发的仅供娱乐但将被某些人使用的软件进行版本控制的指南或标准最佳实践?我认为有必要对这种软件进行版本控制,以便您知道正在谈论的版本(例如用于修复错误、支持等)。
但是我应该从哪里开始进行版本控制呢?0.0.0?还是0.0?然后我该如何增加这些数字?主要版本.次要更改?每次提交到版本控制系统都应该是另一个版本吗?还是只针对在生产环境中使用的版本?
我从最低的(非热修复)段开始版本控制。我不限制这个段落为10。除非你正在跟踪构建,否则你只需要决定何时应用增量。如果你有一个QA阶段,那么可能是在通过QA并发布后对最低段应用增量,然后对下一个段进行增量。将最上面的段留给主要的行为/UI更改。
如果你像我一样,你会将它变成方法的混合,以匹配你的软件进展的步伐。
我认为最被接受的模式是a.b.c.或a.b.c.d,特别是如果你在QA/Compliance中使用。我曾经因为日期是版本的常规部分而遭受了很多抨击,所以我放弃了它。
我不跟踪构建,所以我喜欢使用a.b.c模式,除非涉及到热修复。当我必须应用热修复时,我将参数d作为带时间的日期应用。我将时间参数采用d,因为在生产中真正爆发时,可能会有几个时间点。我只在我为生产修复而分支时应用d段(YYYYMMDDHHNN)。
个人而言,我不反对使用 va.b revc 的软件方案,其中 c 是 YYYYMMDDHHMM 或 YYYYMMDD。
话虽如此。如果你可以 获取一个工具 来配置和运行,那么你就可以避免头痛的版本控制意见方面的问题,而且你只需要说“使用这个工具”... 因为开发过程中的每个人通常都是非常顺从的。