@GGGG430 建议先学一下初中数学，基本的 log 运算什么的，然后搜索一下『宇宙有多少原子』

@GGGG430 这里的 100 指的是被签名参数的长度，100 已经是非常保守的数字的

楼主知道 36 的 100 次方是多大的数吗？

在有『版本控制』分类的情况下你把 SVN 归类为『开发工具』？

在市场行情不好的时候，面试官或者筛选简历的人会仅仅因为简历上一些小瑕疵就直接忽略该简历。

相比于 alpine，你提到的那些系统有更加丰富的软件库、系统各种特性用法的普及度更高，在已有镜像基础上去安装新的程序成本更低。

@Xbluer #21
你看我在 #16 的回复，「你的方法可能在大多数时候是可行的，但不代表这是一个正确的方法」，你都知道 pull --rebase 这个命令了，为何不直接在自己的分支 rebase 一下 company_trunk 而是要绕那么大一圈。

@yuankui #8
「系统分析、拆解师」需要对系统本身的业务十分熟悉，然而大多数公司的业务并不能通过简单的文档来描述，需要靠时间去逐步地熟悉，这就导致这个工种很难众包化，即使众包也会演变成长期的外包合作，对企业来说和雇佣一个全职的没太大区别。

楼主只站在程序员的角度看问题。
对于出钱方（公司）来说，需要能出详细的业务说明文档、测试用例，这个成本可不低，如果是全职的工作可能面对面说一两句话画一两张图就能理清楚需求，远程沟通而且是和不熟悉的人沟通效率并不高，外包小的业务功能并不能降低研发成本，反而会增加管理成本。

就凭楼主这个帖子，大多数公司都不会要你。你是谁？你会干啥？你干过啥？期望薪资多少？求职最基本的几个要素一个都没有，有理由怀疑你这一年半完全是荒废的。

@TomatoYuyuko #3

#app {
all: initial;
}

#app * {
all: unset;
}

这帖子分 3 派，挺楼主派、反楼主派还有分不清加密、摘要、对称非对称加密瞎发表意见派

@jorneyr 需要强大的上下游支撑，比如如何搭建本地开发环境、如何 debug、收集日志等等，如果使用云厂商的方案还得考虑未来是否有可移植性，和云厂商绑死是一个很大的风险。

@WhoCanBeRich 如果对 rebase 理解不够到位，建议还是用 merge 吧。

@WhoCanBeRich 这个就是时间差问题了，假如你在处理冲突时花了较多的时间，那么就有可能出现别人 push 了新的 commit 到远端分支。
你的方法可能在大多数时候是可行的，但不代表这是一个正确的方法，

@leo108 #13 除非楼主之前本地的 company_trunk 与远端的一致

@Xbluer 你仔细看楼主贴的操作记录，是在 company_trunk rebase 了自己的分支，这种情况必然需要 force push。

@Xbluer 在公共分支执行了 rebase 之后又不 force push ？那这个操作的意义何在？


@ColinZeb 你确定 rebase 是一种「推送」方式？

你自己的分支怎么 rebase 都无所谓，但是公共的分支（比如你说的 company_trunk ）执行 rebase 操作的话……没被同事打死真是幸运呢。

把 360 浏览器切到急速模式（误