• Git 提交问题 at 2016年12月18日

    咱们简单点,就分两种:feature 和 target,后者可以是 master / staging / testing ... or any names,反正是你要最终合并的目标。

    Now,问自己一个问题:我为什么要把(目前还在本地的) feature branch push to origin/feature branch?我没有假设什么标准答案,这个过程有没有完全取决于你或你的团队的工作模型。在某些情况下,这个 pushing 是有必要的,比如说:

    我的 feature branch 提交的粒度很细致,step by step 的;并且我们团队有 code review,boss 要求我们在合并到 testing 之前一定要有人帮我做 code review。那么,我势必要给他一个远程可访问的分支,所以我需要先 push local feature branch to remote feature branch

    类似的情况也有别的,根据实际情况自己脑补。接着假设这些前置要求都满足了,该进行合并了吧?但是这又会有变化:我能直接 merge target 吗?这个问题同样没有标准答案。有些团队要求的比较严格(比如说很多开源项目),一定要你用 PR 的方式来合并代码,那么这时候你在本地合并 testing 也没有卵用,因为即使你 PR 了 local merged testing,也许你没有 rebasing / squashing 一样会被拒绝并要求你做出正确的 PR。

    所以归根结底,git 只是工具罢了,没有绝对的应该不应该,最终还是要看团队的具体要求和执行能力的。

  • #1楼 @fubu git-remote 有 get-url 子命令,可以 man 一下看看。

  • 有句话说的没错:

    不要让世界适应你的模型,而要让你的模型适应世界。

    极端的 OO 和 极端的 FP 都有问题。

  • @darkbaby123 是,我刚才看到了,我自己的选定语言里没有添加它,所以一直以为没有呢。

  • @darkbaby123 啥时候有 Elixir 版啊

  • 这个绝对支持啊!!!不过俺 vimscript 的水平一般 😢

    想问一下有没有 layer 的编写教程,比如说我来贡献一个 javascript layer,是不是有了你的 layer 层封装,我基本不要写 vimscript 了?

    大概看了一下 core_config 和几个 layers,nice~

  • 最近全国网络的显著变化 at 2016年12月05日

    #1楼 @darkbaby123 然而我们都知道这是可以存在的……

  • @panxiubin 不是 running /usr/bin/xcodebuild 而是直接 /usr/bin/xcodebuild,你没发现下面在提示:

    command not found: running

  • #48楼 @ugoa 抛开 Redux 不谈,“集思广益”其实并不一定能“加速促进”,Ember RFCs 就是很好的例子。

    一个 Idea 的提出要比真正实现它容易得多,特别是在没有别人参与的情况下。然而这种速度却未必是好事,也许你的 idea 不够周全,也许你忽略了一些非常必要的应用场景,也许你根本就想歪了,其实还有更好的方式能达成目标。

    RFC 的意义就在于最大可能性的排除或削减上述“也许”所带来的副作用,而这种副作用恰恰是很多看似繁荣的社区最大的隐患。

    炒得火热并且用的人多并不一定能实现“集思广益”,因为这个词真正的核心在于“集”,而它要体现在两个方面:

    1. 用户知道哪里应该是集中探讨 ideas 的地方——比如 https://github.com/emberjs/rfcs
    2. 官方应该明确被广泛关注的 ideas 终将会得到官方的支持,或者有普适性足够好的周边支持,比如 ember addons

    而一个 idea 要想足够成熟,它必然要经过探讨甚至争论的“集思”,然后要有人提出相对严谨周密的 solution,要有人写 demo,要有人测试,要有人拿去实战检验……之后才能变成正式的方案交给大部分人使用,让大家一起“广益”。这才是一个靠谱的、负责任的社区应该做的事情。

    没有这些前提,如何把思“集中”起来并广益呢?你引用的 Redux 的例子,其实只是在你看来它很繁荣罢了(因为你其实也对它不是十分了解),可是它并没能做到“集思广益”,说好听一点顶多是“百花齐放”,观赏性挺高罢了。

  • @ugoa 趋之若鹜又能怎样呢?能因此而证明从此便能健康的发展下去吗?

    关于 Redux 造成的问题我在很多回帖里都谈到过,不知道你怎么看,依然认为这些不是问题吗?

    即便使用 Redux 的人很多很多,但是真的懂透彻了,能用好的(包括围绕其周边的一系列 middleware 或 packages)却是少之又少——那么这样就可以满足了吗?事实上,你看看现在讲 Redux 的教程,十之有九还是在基础的 reducer 上绕,翻来覆去都是 todo list / counter 这样的例子,有几个正儿八经谈谈真正复杂的场景的?而 Ember Data 这些年来已经发展到常见的场景都有 adapter 并且几乎都有实际运行的真正的项目(因为这些 addon 都是在实际开发中抽象出来的)。就连 Dan Abranov 自己都说了:You Might Not Need Redux

    事实上,从 Dan 推出 Redux 以来这么久了,有什么本质上的进步吗?这么久了!趋之若鹜的人们大多还在门口绕圈圈,看看 SF/SO 上关于 Redux 的问题都在问些什么吧,绝大多数人都还搞不明白怎么把一个 store 里的状态渲染到视图里,或者怎样发一个异步的 action

    再去 google 一下:github redux async/ajax/promise,看看你能找出多少“解决方案”?一年过去了,分出高下了吗?选出最优了吗?

    所以我不禁要问了:这样的繁荣有多少实际价值呢?Dan 因为 Redux 声名远扬,也加入了 React Core Team,So What?Redux 成为 Official Guaranteed 了吗?非但没有如此,又冒出一个 Mobx 来。这样的循环还要搞多少次?

    一方面喊 Frontend Fatigue,另一方面什么火就往什么冲,我是真搞不懂这种现象 Ember 社区有什么必要好好学习一下的,我还是喜欢现在的 Ember Community,steady as the beating drum

    BTW,上面的话只是借你的话题说说感受,不针对你的评论哈。