[CoolCold]

I may be wrong, but this

> It's all fun and games until someone creates a branch with an updated Dockerfile, you check it out, it alters your container and then you go back to master only to find out nothing works.

ticks some boxes for me - author prefer/works best in solo mode, otherwise such change would be reviewed by team members, before being put into master branch.

[smoochy]

I think you're not seeing the actual point. The review isn't solving the issue. If you have two branches with alternating environments and you switch back and forth between them, how do you suppose your Dockerfile would handle it? What if that change isn't as simple as switching the Ruby version, but "compile and install some software" or some obscure config changes? I mean, it would be breaking all of the time, you'd end up having two containers anyway and you'd be scratching your head as to how to switch between them easily.

[IanCal]

You just build it. I'm not sure I understand the issue.

If you really want then just tag them, but building with a cache would be very quick when you swap.

[ParetoOptimal]

I'm pretty sure everyone prefers "check out branch, run build command" to transparently do the right thing rather than mental book-keeping of "does the state of my docker container match the Dockerfile of my feature branch"?

[IanCal]

Yes, that would be "docker build". Or docker compose if you want to do more things and organise the volume mapping side/other dependencies.

> does the state of my docker container match the Dockerfile of my feature branch"

Why track the state of your docker container? Just build it.