@codingKingKong 原则上我们只有决定要上线的功能才 Merge。
你想呀，因为 A 和 B 随时都跟随着 tip，所以 AB 自己的 tip 就是 dev+feature 的，只要跑通测试，任何时候都可以 Merge 进 dev。如果研究决定新版本只留 B 不留 A，那 A 就留到发布以后再 Merge 就行了。

就算 A 和 B 已经 Merge 了，想要剔出 A 当然也是可以的，两种做法。

1. 非处 x 女座：把 A 分支整个 Revert 掉，作为单个提交放在 tip 上。
Old -> Merge A -> Merge B -> Revert Merge A <- release-x.x

2. 处 x 女座：把历史记录重写掉
Old -> Merge A -> Merge B <- dev tip
首先把 dev reset hard 回 Old，然后把 B 重新 rebase 回 Old，再 Merge 回 dev，变成
Old -> Merge B <- dev tip
...\--->a1->a2->a3 <- A
然后把 A 和 dev 强推回仓库，再让每个人 fetch 一下就行了。

第二种做法要求大家都懂 Git，如果有人不会，还是用方法 1 好了。

如果用的是推荐的 Git flow 流程，也就是 master 部署，而 dev 开发的话，最差也就是重建 dev 分支，Rebase feature branch 然后重新 Merge 而已。Git 本身是很灵活的，怎么玩都行……

Mybook 是氦气，Easystore 也是氦气，我两个都拆过，Easystore 拆起来比较 Easy。
拆 Mybook 的时候硬盘直接从壳子里跑出来飞到地上去了。

签署一份《保密协议》
并
约定……

额，你不知道这个 并 是什么意思？

location /app1
location @ app1
location /app2
location @ app2
location ~ \.php$

一共 5 段吧，你觉得恶心吗？我觉得还好吧，正常操作。

只是发牌姬不喜欢你而已……

本地人可以打一顿解决，如果你上头有人的话……
否则还是报警吧……

刚想说，这就是野指针啊。（然后楼上说了。）
随便指向内存中一块不属于你的地址，出来的是啥就是啥。
如果内核看你不爽，可以直接杀掉你的进程。如果他没那么凶，那就让你随便读点内存里的辣鸡数据。

@codingKingKong 「 tip 」指的是每个分支的顶端（或者说末端）。
rebase 到 tip 上，也就是 rebase 到 master/dev 的最新提交，然后再做 feature->master/dev 的 merge。

比如 dev 是 9/1 提交的，9/1-9/20，两个人 A 和 B 分别开发了两个不同的 feature。
A 现在要合并 A 分支，当然是没问题的。
然后 B 要合并的时候，我们要求 B 需要先 rebase 到合并完 A 的主线的最新提交，然后才允许 B 合并。

@xrlin 我不觉得 IDE 可以弥补语言的表达能力……

上班用 mattermost 交流。
下班以后工作群全是 QQ 的。
微信……嗯，并没有装。

买房然后收房租。

@puritania 一般是使用 Preallocate 来预留的。

根据文件系统的实现。
写入文件的时候可以预先提醒内核你要多大的空间，方便文件系统给你预留。

我没看过 mp3 的结构，但是我觉得应该是拿不到的。

我猜你的 m 和 f 键互换了。

你说 ffmpeg 能读出来，有具体日志吗？
我觉得 ffmpeg 可能是去猜的。比如解码以后看看实际的有效位深是多少。

先说什么发行版什么版本。

@codingKingKong
AB merge 方向这个我也不是很清楚，但是如果本身没冲突的话 3-way merge 完的结果应该是一样的。有冲突的情况下，可能先合并的更改会改变后续更改的参考系，所以可能会产生结果不一致。

至于项目管理的话，我们一般是一个 feature 一个分支。一旦某个 feature 定稿合并以后，其他 feature 分支需要 rebase 到 tip 上然后才能 merge。

所以我们的分支图大致是这样的：

https://i.imgur.com/dG0EM7G.png https://i.imgur.com/XyH44ny.png

以及之前的反面教材：

https://i.imgur.com/U54T03C.png

（不知道你能不能看到图。）

另外 force-push 一般是不会丢 commit 的，只要之前那个正常 push 的人重建分支就行了，很简单的。
用 Git 这种多人协作工具，一定要保证每个人都会用 Git，然后才能放进来做贡献。之前我进公司以后看到公司里十来个完全不懂 Git 怎么用的人，真的是心态爆炸。

@k19870203 是 3-way merge，但是 apply diff 的顺序是不一样的吧。先 apply A-O 再 apply B-O，还是反过来，可能就会影响冲突判定了。

至于解决冲突，因为解决冲突本身是包含在 Merge commit 里，实际上一般不会有人特意去写这次 Merge conflict 到底改了哪些部分，甚至都不会说这个 Merge 做过了额外的修改，所以追溯的时候就会出现一个没有修改说明的修改。可能合并前测通了，合并后崩了，然后你发现是 Merge 的时候有人改错代码了。

买充值卡冲进账号里比较靠谱。
如果是别人开号给你，或者是教育版，当然都是不靠谱的，能用的时候用，没了就没了。