@hantsy 确实是这样，不过对于本来就只有几个单词的改动了，简单也是可以的。并不一定要拧在条条框框上。一个很明显的例子，有的自从学了 flow 以后，就必须认为 master 丢 稳定版，然后建个 development 分支进行快速开发。实际上 对于 git 来说，分支是平权的，都是 引用，引用到一个 commit 点， commit 追溯寻宗到 初始 commit 就构成了 分支。

你修改的是 磁盘镜像，无论是 编译时 link 或者 dlopen, 运行的时候都会先将 so 文件加载到内存中，只要不是重新从磁盘中读取，那么就依然使用的是 旧的 so, 而 Windows 不一样， Windows 的 dll 会被锁定，然后，替换不了。
这也是为什么 linux rm -rf / 系统还能跑，重启起不来了。

我反正 commit message 随便写，反正大伙看 diff 也不会不懂

很简单，开另一个端口，然后在 NGINX 或者 Apache 或者 IIS 判断 UA , Git 的 UA 是 git/xx 然后代理过去就行了。

内核经常被自动 remove 算一个

https://msdn.microsoft.com/zh-cn/library/5bdb6693%28VS.80%29.aspx
0x100 =>256, BYTE 是 无符号 8 位整数 ， 范围 0 到 255

@msg7086
@mozartgho
svn 远程仓库肯定很大，但是也不会很大的， Subersion 基于差异，而 Git 每一次修改都将修改后的文件使用 zlib 压缩成一个 Object ，名字是 hash 格式如 {2}/{38} 存储在 .git/objects 目录 ，使用 git gc 后，写入到 objects/*.pack 对于大文件的修改， git 很容易出现体积陡增。这样的好处是，不要通过差异计算获得文件，只需要找到指定的 对象 id 然后 解压即可。

如果团队协作，项目非常大，建议使用 Subversion 或者是使用 Git 用 Submodule 机制。

Subversion 部分检出，只需要将开发者开发指定的分支或者指定的目录检出来即可。
Git Submodule 不同的开发者操作不同的 Submodule ，然后，技术主管在 总的 git 仓库设置 Submodule 的 Commit, 这个实际上可以编辑的。

分支模型， Git 的分支是均权分支，默认分支，主要指的是 remote 指向的存储库的 HEAD 里面的引用。
实际上，随着 Github 和 OSC@GIT 等代码托管网站的兴起， Pull Request 机制是比较适合 Git 的，这里带来的问题是 fork 仓库带来了磁盘存储的压力，多个 fork 请求， IO 居高不下，磁盘空间的需求几乎是呈指数增长的。

而 Subversion 的分支模型，更像文件系统目录结构，每个人对目录有不同的操作权限。在 Subversion 的官方仓库，也就是自举仓库 http://svn.apache.org/repos/asf/subversion/

trunk/ ......... The latest development sources. When people say
"Get the head of trunk", they mean the latest
revision of this directory tree.

branches/ ...... Various development branches. Typically a branch
contains a complete copy of trunk/, even if the
changes are isolated to one subdirectory. Note
that branch copies are generally removed after
they've been merged back into trunk, so what's in
branches/ now does not reflect all the branches
that have ever been created.

tags/ .......... Snapshots of releases. As a general policy, we
don't change these after they're created; if
something needs to change, we move it to
branches and work on it there.

他们的快速开发主要是 trunk, 而发布分支主要是 branches 下载分支， tag 也就是里程碑。

@zioc 查看 svn merge 命令，也可以获得 修改的 diff 然后 trunk 合并。

svn 的逻辑还是第一种 好， trunk 做主开发，定期新建 branch 然后 修复 bug ，发布 在 tag, 修复也在 branch ，
包括 gcc subversion llvm reactos 这些项目使用 svn 托管都是这么做的。

在 C:\Program Files (x86 )\Windows Kit\10\include\10.0.build.0\ucrt

@Smilecc 说的是正确的，如果没有指定文件的绝对路径，那么，程序就必须在当前目录下，如果你使用 Visual Studio 调试或者运行程序，那么这个时候的当前目录是程序源文件目录，并不是 Debug 目录，你如果在 Debug 目录中启动程序，一般是能够打开文件的。如果你要打开 exe 所在目录的文件，应当使用 GetModuleHandle (nullptr,buffer,MAX_PATH ) 取得 exe 的绝对路径，并使用 PathRemoveFileSpec 去除 exe 文件名，然后使用 strcat (wcscat ) 拼接路径。最后通过绝对路径打开文件。

@secondwtq 构建文件并没有解析 include 的能力，以 Makefile 为例，最好在依赖中显式的指明 头文件，如果一个构建系统并没有将头文件的添加到依赖，那么头文件的修改也不会有新的编译响应，当然，一些构建系统会根据文件 Hash 来检测，这些就需要存储到一个数据库文件或者是缓存文件。改动了 cpp 基本上都会触发编译。

Hello.obj:Hello.cpp Hello.h
cl -c Hello.cpp

@nozama 构建系统一般只会检测 源文件的时间戳，然而，不一定检测头文件的时间戳，只有当 目标的时间戳比依赖的时间戳旧时，构建才会再一次发生，重新生成不是这样。

删了 ~/.ssh/known_hosts 最近攻击较多，用了 高防ip，ip 变化了。

@mozartgho 这个不成问题的，官方有提供预构建的，安装后，Visual Studio 可以使用 clang 来编译项目，当然需要设置好编译器参数. http://llvm.org/builds/ 也可以自己构建，使用 ClangSetupvNext （http://fstudio.github.io/clangbuilder/）可以自动下载和安装构建环境，https://sourceforge.net/projects/clangonwin/ 提供了一些预编译的包 不过没时间更新了。

@Threezj 那你手动安装那个msi文件先，VS的安装确实值得吐槽。一般在Windows 8.1上比Windows 7的问题少很多。

你把iso镜像下下来，然后清除TEMP目录的临时文件，解压iso镜像，然后重新安装，当提示你找不到时，Browser按钮在iso解压目录查找即可，这个问题一般是临时文件被破坏了。或者是网络有问题。

感觉Python的要求都好低，上面每一个是难点。

@ether 最终还是会用llc 编译成机器码的。很jvm是不同的