@zhaol 在他的 feture 合并前，应该准备好 4 个分支：1 你的 feature ，2 他的 feature ，4 有他 feature 的版本分支，4 没有他 feature 的版本分支

我们之前的实践是，有一个接受所有 feature 的分支，比如 master ，然后给每个要发布的版本建 release 分支，他先写完后合并到 master ，你写完，rebase master ，合并。此时 master 上有两个 feature （ 0-2-1 ），而 release 上还什么都没有。 像 gitlab 有 自动 cherry-pick 的功能，web 界面上点一下可以把整个 MR （比如你合并 master 那个 MR ）里的所有 commit 都 cherry-pick 到另一个分支上（ release ）。pick 完 release 看起来像是（ 0-1 ），但 1 的那些 commit 不是原始 commit ，是 cherry-pick 重新生成的。

如果 web 界面没有这个功能，就只能在本地手动 pick 一堆 commit 。不过鉴于 release 分支一般也不需要保留修改历史（ master 已经有了），所以可以把 feature 的所有 commit 都 squash 成一个 pick 给 release ，这样手动也不会很麻烦

@cyang812 rebase 后分岔点在基分支的最前端，merge 的分岔点是基分支上历史中的某个点。rebase 的历史永远是线性的，merge 会织出复杂的演化网。

rebase 目标分支和本分支不对等，你基本不可能搞错（不可能试图把 main 拼到 feature 上，只会把 feature 拼到 main ）
而 merge 就可 tm 难说了，feature merge main 和 main merge feature 观感上根本没什么区别，看起来也都很合法，但形成的历史网是不同的，出问题的时候根本没人有能力搞清楚发生了啥

其实没有「远端解决冲突」一说，所有的合并和冲突解决都是在叶子节点上或者说都在 git 的「客户端」进行的。

web 界面只是自动做了一些额外的事情而已，跟你在本地用一个 GUI git 工具是一回事。




> 当我的 feature 开发完毕后,origin/main 可能已经更新了很多个 commit(从其他 feature 合并而来),很可能存在冲突

此时你 **不应该进行任何 MERGE 尝试**。

1. 首先应该在本地切换到主分支（ dev/main/master ），拉取远程的状态。由于你不可能直接在这些分支上修改，所以这一步不会产生任何冲突，仅仅是快进
2. 切回到你的开发分支，把它 rebase 到主分支上，此时产生冲突，resolve ，重新 commit 。
3. 由于到目前为止你还是只修改过你的独占分支（就算有远程也是可以随便 push -f 的那个），所以不会对其他人产生任何影响。
4. push 你 rebase 过后的分支，开启或刷新 MR





之所以采用不断 rebase 分岔点的方式是因为，如果你不进行 rebase ，merge 操作时是一个三路合并，而三路合并是一个**既复杂又存在危险性** 的操作


(!!) 其实我本来想简单解释一下为什么三路合并会出问题，但在我搜索看了近一个小时文章后，我选择放弃解释：
https://www.waynerv.com/posts/git-merge-intro/
https://git-repo.info/zh_cn/2020/03/something-about-git-merge/
https://actake.github.io/2021/03/21/git%E5%BF%85%E7%9F%A5%E5%BF%85%E4%BC%9A-%E5%88%86%E6%94%AF%E5%90%88%E5%B9%B6%E9%82%A3%E4%BA%9B%E4%BA%8B/





(!!) 因为这已经是我至少第 4 次搜索这个问题然后仍然没有完全搞懂了


如果采用 rebase - merge FF 的方式，合并操作等同于在对方分支上把你做过的操作重放一次，心智负担和风险要小得多。只有一个麻烦，因为是重放，当你的 commit 序列一开始就与对方冲突时，这个冲突会有传递性（对方是 A ，你第一个提交把 A 改成了 B ，后面的提交全部在用 B ；发现冲突后你决定改成 C ，那么当你 rebase 重放的时候所有后面的提交都会不断发生 B 和 C 的冲突）。但这都可以通过减少 commit 修改量和 squash 改善，相比起三路合并能由（虽然存在疏忽的）正常操作产生 **无感知的** 丢修改相比，成本显然要低得多

1. find： https://www.runoob.com/linux/linux-comm-find.html
2. 把路径字符串扔进 python ， ''.join(路径.split('/')[::-1])
3. mv 原路径，新路径

三步，够方便不
我猜你想问 windows 平台。

1. 视频文件有封装格式和视频流编码格式两个概念（其实「格式」不准确，但正因为这两个概念容易混淆所以我用相似的词提醒）
2. 封装是指 mp4/avi/mkv 这样的容器格式，除了视频流外还可以封装音频流、字幕、音画同步信息等额外的东西。你的 test2.mov 和 test2-2.mp4 由于没有经过重编码所以它们的主要内容，即原来那个视频流，是完全一样的，只是采用了不同封装而已，类似一个 gz 压缩一个 zip 压缩
3. 视频流的编码指的是 mpeg1/h.264/AV1/hevc 之类的算法，更先进的算法可以实现更高的清晰度、分辨率的同时降低所需的空间大小。以前 av 画质时一个视频几百 m ，现在 1080p 一个视频还是几百 m ，这是编码方式在影响
4. 在采用同样编码方式的前提下（比如你展示的 3 个文件视频都是 x264 编码的，它们都是 h.264 视频流），能控制的参数也还有非常多。不同的采集设备和播放设备能支持的参数不同，所以有非常多级的标准来限制编码器的数十上百个参数变量。比如老旧便携播放器解码能力很弱，甚至没有并行指令集（ SIMD 之类的指令集），那视频就不能编码得太复杂，跟手游不用高精 3D 模型一个道理。
5. 那么具体到算法上是些什么差异呢： 前后帧变化估计的精确性、变化位置的搜索方式、搜索范围、压缩时寻找最佳字典的复杂度、区域片段「重要性」占整体的权重……

打个粗浅的比方，完美的编码：
「 这一帧的像素由前 20 帧的 x 到 y 位置卷积后与 10 帧后的 z 位置相乘得到，下一帧的图像人肉眼不可能看清，所以直接使用本帧 1/4 分辨率数据。」
辣鸡编码：
「这一帧有 1920*1080 个像素，但我只记了一万个位置的值，分区平摊吧，依次是 1.1,0.9,0.132,0.15768……」
显然完美编码体积就能很小同时也很精确。辣鸡编码就又占地又粗糙。但前者要得到这么准确的前后参考数据是要经过大量反复多次的搜索和迭代的，这也是编码器编码要花大量时间的原因。实际应用时，往往会在编码耗时和成品质量 /大小之间取舍一个合适的平衡

我说一句话： 它们这么牛逼你为啥用 sublime 做视频？

@vcfghtyjc
> 为啥会需要引用两次

你先再看一眼 1L ，然后看这个
https://onlinegdb.com/b4qgRG-ZS


哎，你别说以前可能还真有人认为会有需要 include 两次的地方

能让编译器「自己做这个事情」的提案叫 modules ，是一个有近 10 年历史的卫星，当然这跟 c++存在的漫长时间相比并不算什么

https://en.cppreference.com/w/cpp/compiler_support 在这里搜 modules 有惊喜

p.s. 别看这个 proposal 是 2019 年的，但其实随便一搜就能找到过去的弃案比如 https://isocpp.org/files/papers/n4214.pdf

说一个会的人都知道但没学过可能无法想象的事：

c++的编译器只会处理「一个文件」，include 的作用是把所有<>里的文件全都拼在一起



字面意思，拼在一起。include 两次就拼两次。

如果是你先提到有 webpack proxy 这种方式然后追问的，那我觉得不冤，如果是在说

「本质上有代理 /浏览器 /HTTP 规范三种方式」然后让你把所有代理配置方式都说一遍，那我觉得很傻逼

如下机制必须使用指针：

type T struct {
Field int
}

func (t *T) SetValue(v int) {
t.Field = v
}

var t T
t.SetValue(1) // 否则 t 的值永远不会改变

如下结构传递值会有问题：
defer func(v T){someChan <-v}(vv) // channel 捕捉不到 v 的最后状态而是当前值

gorm 的 scan 使用了大一 C 语言教科书级别的指针传递：
db.Where("id = ?", 1).Scan(&ModeledValue)




无脑用指针的话：

func (*T) TableName() string {
return "t_"
}

你要写 db.Table((&T{}).TableName()) ，本来可以 db.Table(T{}.TableName())




还有浅拷贝的问题：

type T struct{v:int}
type U struct{t *T}
type N struct {u *U}

t := T{v:1}
u := U{}
n := N{}

n.u = &u
u.t = &t


func foo(n *N) N {
return N{u: &U{t: n.u.t}}// 我想「用 n 的值初始化一个新 N 」
}

newN := foo(&n)
newN.u.t.v = 2
n.u.t.v == 2 //但其实 n.u.t 被改了


ref: https://go.dev/play/p/74Q6bC13xN0

@awen233333 说明大部分人都默认标题观点但碍于面子或者奇怪的政治正确只好挑些其它毛病。你看不认同的人就会拿出例子来做对比

> window 的注册表可以不？

我都想替微软谢谢你 ……


redis 就是用来干这个的，你又不想用。数据库自己都有锁会处理好的你又不用，整个 sqlite…… 不会每个 app 自己使用一个 sqlite db 文件吧

要不我再指条路，叫 CreateFileMapping() ： https://docs.microsoft.com/en-us/windows/win32/memory/creating-named-shared-memory

我觉得又是个表达问题

我猜 OP 的原意是在反序列化的过程中中断读取文件流
你是否在找类似于
http://rapidjson.org/zh-cn/md_doc_sax_8zh-cn.html

这样的东西？

显然是什么姿势不对
https://i.imgur.com/92Bodi1.png

https://i.imgur.com/27tFZ5h.png

别人问我为什么是这个壁纸我一般会回答

「因为很护眼」



但其实是因为这是我设过的唯一一次壁纸之后一直账号同步就再也没管过了
（ macos 上就一直是默认）

卧槽我第一次见把开发软件也算进项目成本的项目，兄弟咱公司名叫啥 :doge:

害挺难，最高纪录 42 分