@rannnn #7 创始人道歉了

好处之一是可以避免事务脚本，把业务逻辑以面向对象的形式进行抽象，增强复用性、可测试性。

用了两年 11 的表示选择 12.9

这是没掌握到下载 bt 的正确方法。一般用 qbittorrent，添加好 github 上的 tracker 地址，下载的网络要有公网 IP，并将路由器开启 upnp 。

@agagega #77 感觉靠谱

或者是端口转发你那台电脑 ip 的 3389 端口，然后通过自带远程桌面连接也行，不过 VPN 感觉会安全点。

可以让公司开一个 VPN 让家里连，然后直接通过局域网的 ip 用自带的远程桌面连接（如果是 Windows 的话）就行了。

厉害，让人联想到三星之前退出的 PWA

@unco020511 #20 说 pr 脱离了 git 流程其实不太准确，因为所谓的“git 流程”其实指的就是 git 工作流。git 工作流有很多种，涉及到 pr 的叫 GitHub flow，涉及到 mr 的是 GitLab flow，它们都是 git 工作流的一种。在实际公司的开发者，也可能会 fork，也可能没有，这主要是由公司使用哪种 git flow 决定的。

@unco020511 #20 首先你可以参考下这个链接，对 pr 有详细解释 https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests

pr 和 mr 其实是完全一样的，它们可以发生在不同的 repo，也可以发生在同一个 repo 。
在同一个 repo 时，需要指定 pr 的源分支和目标分支（必须是不同的分支）。
在不同的 repo 时可以分支的对应可以任意。比如我们要像一个开源项目提 pr 时，除了默认的 origin 指向我们 fork 的仓库，还需要一个 upstream （上游）指向主仓库。这时候我提一个 pr，就可以这样对应分支：origin/master （源）——>upstream/master （目标）。

抽几条回答一下

1. 首先如果是一个私人分支的话，你要同步 master 的代码，这时候用 rebase 其实是最好的，因为不像 merge 可能会产生一个 merge commit，可以一定程度上保持提交历史的简洁。
如果是你的分支（假如 feature 分支）开发完毕了，想合入主分支，这时候用 merge 比较好，因为可以保留你的分支痕迹（--no-ff ）。但是有很多著名的开源项目合入主分支时也是用的 rebase （比如 angular ），这样主分支就是一条直线，很简洁。

3. 说到 pull request，直译过来就是拉取请求，这个怎么理解呢，就要说起在 GitHub 上的协助方式。在 GitHub 上有一个开源项目，它可能会收到来自其他人成千上万的贡献，如果大家都提交到一个 repo 的话，就可能会很混乱。所以非 member 的开发者是对主仓库没有提交权限的。这时候怎么做贡献呢？就要 fork 一份主仓库，这个 fork 的仓库是完全属于你的，你可以随意提交。当你想把你的提交贡献给主仓库时，就可以发起一个 pr （拉取请求，即“主仓库 member 拉取你代码的请求”）。然后主仓库的 member 拉取了你的代码 review 后决定要不要并入主干。所以 pr 机制就保证了，既可以保持主仓库的整洁，又可以方便的接受别人的贡献。

学习了，一开始还以为不行。

你应该强硬一点，该问什么就问什么，毕竟现在是你给钱，底气在你这边。

从实际出发，确实是买家具的亏，好一些的家具花个几十万也有可能，也不是小钱。房子是资产，是会增值的，家具只会贬值。

假如你房子是婚前买的全款，并且是你一个人的名字，确实离婚的时候你老婆分不到一分。建议可以这样，你们拟定合同，给你老婆买家具的钱所对应的房子的占比，平时的钱可以就不要太计较了大家的一起花，全额上缴工资就不必了。

@minami #19 普及率高还可能是因为，买的是 JB 的 All Product package，所以顺便就能用