startry 最近的时间轴更新 startry 最近的时间轴更新 |
startry=。= 没想好 🏢 滴滴出行 / iOS研发工程师 V2EX 第 132868 号会员，加入于 2015-08-14 10:24:16 +08:00 |
xStartry
杭州
startry
| 开源截屏库, 可以用来截取网页内容然后做分享功能 分享创造 • startry • 2016-03-11 20:07:38 PM • 最后回复来自 fhefh | 1 |
startry 最近回复了
2016-01-26 17:21:18 +08:00 回复了 hongfeiyu 创建的主题 › Blogger › 你们的博客上有多少文章了，来晒晒吧 |
不到 10 篇的弱弱飘过 http://blog.startry.com
2015-09-09 14:16:21 +08:00 回复了 zioc 创建的主题 › git › 从 git 迁到 svn，求教大家单位上 svn 都是怎么用的？ |
第一种方案。 一份代码理论上就应该保留一个发布的口, Trunk 是最好的选择。
如果在分支上发布, 那么 Trunk 不能保证是最新最稳定的, 分支上才是最稳定的。
如果使用第一种方案, 发布了 1.0 版本, 切换到分支开发下一版本, 1.0 出 bug 回 Trunk 进行修改。问题是 Trunk 有时候因为协同等原因会被破坏, 这个时候需要 tag 来恢复 Trunk （当然回滚也可以, tag 纯粹最为 bak )。保证无论何时多个部门多个团队协同不会出现太大的问题。
方案二的话需要无时无刻的把 Trunk 往分支里合并, 发布后合并进入主干, 每次需要下一个发布者承担相应的风险
如果在分支上发布, 那么 Trunk 不能保证是最新最稳定的, 分支上才是最稳定的。
如果使用第一种方案, 发布了 1.0 版本, 切换到分支开发下一版本, 1.0 出 bug 回 Trunk 进行修改。问题是 Trunk 有时候因为协同等原因会被破坏, 这个时候需要 tag 来恢复 Trunk （当然回滚也可以, tag 纯粹最为 bak )。保证无论何时多个部门多个团队协同不会出现太大的问题。
方案二的话需要无时无刻的把 Trunk 往分支里合并, 发布后合并进入主干, 每次需要下一个发布者承担相应的风险
2015-08-14 19:05:38 +08:00 回复了 fwrq41251 创建的主题 › 编程 › 问一下各位都是如何转语言的 |
自己创造机会, 自己去尝试用想学的这门语言去实现一些自己的想法, 或者移植人家的应用, 总而言之, 通过实践来督促自己学习哇，否则很难持久。
Select Language