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
终于可以正常修改代码了，太棒了
