小版本为啥一直不升级系统

同时有 12mini 和 13mini 的路过

现在的选择是 trade in 13mini 把 12mini 留手上使用，虽然 13mini 的续航好一些也有些进步，但突起的摄像头导致手感比 12mini 差太多了

new 操作法是一个语法糖，这不是基本常识吗

readkit

但是，最近发布了新版实际上是 universual 版，用户体验全面倒退，所以还是一直坚持用只支持 Mac 的老版本

git push 创建新分支或老分支
命令行自动就会出现一个创建 MR 的链接, 点进去就完事了

-- module.ts
if (process.env.NODE_ENV === 'production') throw new Error('DEV_ONLY');

-- build.sh
grep DEV_ONLY -R bundle/ -q && echo 'build failed' && exit 1

brew install avibrazil-rdm

随便选一个 16:10 的分辨率就是

基本知识
要么你的项目要配置成多个 entry
要么就在代码中使用 import 函数或其它方式创造 split point 来去除强依赖

因为 utf8 是一个安全的编码，确保在任意地方截断后都能 recover
举一个反例，gb 编码就不是安全的编码，在半字中间阶段会导致所有编码全部错位
更差的例子是 big5 ，允许使用 ascii 字符作为编码的一部份，导致一些 markup 语言（包括 ini ）直接出错

如果 fork 的 repo 或分支已经删除了就不可恢复了, force push 的目的是恢复 PR 状态, 至于上游是否 accept 那是另一个无法控制的事情, 先恢复分支再删除 (而不是已经添加了很多新 commit 的状态) 的好处就是再次打开 PR (可能因为删除分支或 repo 已经自动关闭了) 查看的时候, 能看到正确的 commit

找到旧的 commit ，force push 上去，然后删除分支或 fork

楼主真是角度清奇, 万万没想到连名称空间都能作为吐槽点开喷

看来大家都很喜欢玩 1.0 的 npm 抢包名的游戏

简单回答，不能

branch A: a -> b -> c
branch B: a -> b -> d
branch C: a -> b -> e

请问 C 是从 A 还是 B 分支出来的?

这是一个伪问题

正确的问题应该是, 找出 C 和一堆分支(比如 A / B) 的基点 (就是上面已经有人回答过的 merge-base)

曾经写过一个很简单的脚本完成这个任务

git merge-base HEAD `git for-each-ref refs/remotes/origin/master refs/tags | cut -c1-40`

可以找到当前分支和 master 以及所有 tags 的最近的交点, 至于这个交点应该判定给 master 还是某个 tags 那只能自己判断

当然可以基于这个脚本改进一下, for-each-tags 执行 git describe base-commit, 数字最小的就是可能的答案

洋紫荆（学名：Bauhinia variegata ）是一种豆科苏木亚科羊蹄甲属的有花植物，为一种落叶小乔木，俗称兰花木、印度樱花、南洋樱花、马蹄豆、白花红花羊蹄甲；洋紫荆，港澳称为宫粉羊蹄甲，台湾称为羊蹄甲

moduleA: function() {
definedProperty(module_a_export, 'a', methodA);

function methodA() {
}

function methodB() {
}
}

moduleB: function() {
module_a_a = imported_moduleA.a;
}


webpack 大概做的是这样的事情, 通过依赖分析, 标记每个 export object 是否有被引用, 只有被引用的 object 会生成 defineProperty 的文件头

实际上 webpack 不会删除任何内容, 即使 ModuleConcatenationPlugin 把所有模块都连接成一个模块

最终是通过 minimizer (terser 或以前叫的 uglify) remove dead code 实现

git 是去中心化数据库, 请自动朗读三遍