好车说不上

就是，大！
如果你还在意别的，那就可以考虑其他的了。
如果你更在意空间，那就只有它。

不要再用 ftp 这种古老又不安全的协议了

没有了

微信现在不行了，老卡可以随意支付方式

你可以谷歌一下，特斯拉

飞度，低配雷凌


看看保有量排名

@sunnyday1 #7

去仲裁，在仲裁的时候，没有所谓最低标准的说法。
该交多少就交多少，补偿给你也是按照足额计算的。

如果最低标准是合法的，那其他公司都是傻帽？

并不应该，互相商量到一个平衡点。

要买 ssd 硬盘，抗摔

也没有任何隐私可言，public 群可以看到任意聊天记录

月卡略贵，关键看朋友是不是都在

1 区，BL，已建号，充半年卡

300 就别说自己是 nas 了！

@firhome #22

1. 按照 git-flow 流程 hotfix 是从 master 拉取的。完成发布后合并到 develop 和 master 内。

解释一下版本号
x.y.z

x = 大版本号，上一版本和下一版本并不兼容
y = 小版本号，上一版本和下一版本理应考虑兼容
z = hotfix 号，解决各种 bug 问题。


2. 按照你说的情况，是的！但按照 git-flow 规范，某个时间只应存在一个 release 版本。
比如当前是 1.1 的 release，你还在测 1.2 的 release ？毫无意义啊。


但还是那句话，国内公司基本没法按照这个流程来。

@mlhorizon #50

+1

@firhome #19

看了一下你的问题，给 2 点建议

1. 一般不叫 test 分支，而是叫 develop 分支，其实并不是纠结名字，而是，这个分支上的功能实现，就是所谓的 [开发版]
2. 其实都是要测 3 次的，不管是功能第一次合并到在 develop ( test ) 上，还是最后拉出的 release 上。
- 第一次测试，代码自测无问题，feature 分支。
- 第二次测试，合并到 develop 分支，和其他功能一起测试。
- 第三次测试，拉出的 release 分支，可能会在 develop 分支上截取某个时间点，作为 release，上面 A 功能满足，B 功能可能没有。需要最后回归测试一下。


终告：国内公司不会遵循这种流程，因为太多的项目做了一半要砍掉。所以，从 git-flow 的流程上来说，无解！
但，实际操作中，他们最后会选择：
A 功能自己测。
B 功能自己测。
C 功能自己测。

生产上最后的情况，A 发布，B 不发布，C 发布，怎么办？
大家都上生产，出问题了就是事故，不出问题，下班回家。A+C-B 这样的代码永远都是会最后上生产了，测试才有机会测试这样的最终打死不修改版。

$mail->Password = 'ybhfajzdwkebjb'

给钱