startry's recent timeline updates startry's recent timeline updates |
startry=。= 没想好 🏢 滴滴出行 / iOS研发工程师 V2EX member #132868, joined on 2015-08-14 10:24:16 +08:00 |
xStartry
blog.startry.com
杭州
startry
| 开源截屏库, 可以用来截取网页内容然后做分享功能 分享创造 • startry • Mar 11, 2016 • Lastly replied by fhefh | 1 |
startry's recent replies
Jan 26, 2016 Replied to a topic by hongfeiyu › Blogger › 你们的博客上有多少文章了，来晒晒吧 |
不到 10 篇的弱弱飘过 http://blog.startry.com
Sep 9, 2015 Replied to a topic by 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 往分支里合并, 发布后合并进入主干, 每次需要下一个发布者承担相应的风险
Aug 14, 2015 Replied to a topic by fwrq41251 › 编程 › 问一下各位都是如何转语言的 |
自己创造机会, 自己去尝试用想学的这门语言去实现一些自己的想法, 或者移植人家的应用, 总而言之, 通过实践来督促自己学习哇，否则很难持久。
Select Language