emm，如题所示，那个人就是我。
背景 #
事情是这样的。
我从上星期开始，修改项目的源代码，然而提交了多次，容器代码并没有改变
后来在一遍文章上发现，还是要重新 build，本以为找到了救星了。
奈何发现执行docker-compose build，容器并没有重写，明明我是写了的，为什么会这样呢？
不知道自己已经几次看了 Dockerfile 文件，明明有 copy 命令，可就是不执行，或者说，这个文件就是不执行。。。
于是在今晚，重新阅读官方安装文档的时候，发现了问题。 它告诉我(官方文档真的得仔细读！)，
Alternative: if you want to build the images locally with unreleased changes run the following command. It will take some time to build CVAT images.
docker-compose -f docker-compose.yml -f docker-compose.dev.yml build
进展 #
虽然第一次没有完全理解这句话的意思，抱着试一试的心态，运行了它。 结果真的重新 build 了容器！
以现在差不多理解的思想去读，这句话其实就是告诉我们，如果我们要运行二次开发的版本就要重新 build。 哈哈，这个时候，你可能又懵了，那原理是什么？
解释 #
如果你懂得这个命令的意思，你可以跳过这里。 我不是，我今晚才知道这个命令。 这里，我以我理解的知识讲述一遍。
我们平常使用 docker-compose 最熟悉的命令就是，docker-compose build
这个命令十分常见，它默认执行的是docker-compose.yml
我说到这里，你可能就知道上面命令的意思了，
没错，你可能猜对了。
上面的命令是指定文件进行 build
这里又同时指定了两个文件，那也是可以的。 这也是为什么我前期一直 build 没有反应的原因。
结束 #
为什么上面还有个 docker-compose.dev.yml 其实你去百度，你以为又是某某规范的时候，那就错了，这就是作者自己自定义的。
而这里面在 docker-compose 基础上，又增加了 build 参数。
(总算点题了)
services:
cvat:
build:
context: .
有了这个参数，我们才能使用我们目录下的 dockerfile 文件。 如果没有这个，如果你写了 image，指定了仓库的话，那么就会跳过这个文件，直接拉取仓库里的
又回到上面的问题，为什么指定了两个，因为官方在 docker-compose.yml，就是写了 image，拉的是官方远程仓库，而在 docker-compose.dev.yml 写了 build
这里告诉我们两点，
- dockerfile 就是本地的仓库链接(这里想说的形象点)，有了它，本地修改的记录才能更新
- dockerfile 最后构建过程形成文件和官方远程拉取是差不多一样的
- docker-compose build 时候，可以指定一个或者多个,而它采用覆盖更新，dev.yml 在后面，它的 build 就覆盖了 compose.yml 的 image
终于可以正常修改代码了，太棒了:@(中刀)