There are a couple different ways to implement this type of workflow. You can use tools like VSCode's remote development features, you can use an IDE/editor with built-in rsync/sftp capabilities, you can also use git via a local command line (though that defeats the purpose), or a tool like Mountain Duck if you want to 100% eschew a CLI. Admittedly, for myself, I prefer to simply shell into a remote machine and use vim. But, that's "remote editor; remote runtime".
The remote runtime can be either a local Linux VM or a remote VM. That's kind of the beauty of this approach. You can generate a machine image and have a consistent environment either locally or remote, depending on your current needs. Obviously, when working with a local VM, you can use host mounted directories using one of the various tools for doing so, in a much more efficient manner.
I tend to not run git locally, but prefer to run it on my source on the remote environment. This is mostly because I'm not wanting to use the native Mac OS userland.
I do not run tests locally, that's very much the intention.
I don't have a link to an article handy. You already seem familiar with the VS Code tooling, so it's a good place to start.
I'm not a pedant about this. There are some rough edges, especially in the file sync'ing for the local editor, and integration with IDEs. But you can get most of the way there and be pretty happy.
edit...
When I was working on ChromeOS, the actual workflow was more like "host OS" -> "local VM" -> "remote VM". The Crostini environment itself runs in a local VM and container. So you would essentially be running an editor inside that local VM (I ran VSCode this way for a hot minute), and I was working with an sshfs mounted src directory from a remote VM. This was mostly because I was doing work against a dev environment that relied on a number of hosted services that were only accessible to the remote VM. The hoops we sometimes have to jump through...
The remote runtime can be either a local Linux VM or a remote VM. That's kind of the beauty of this approach. You can generate a machine image and have a consistent environment either locally or remote, depending on your current needs. Obviously, when working with a local VM, you can use host mounted directories using one of the various tools for doing so, in a much more efficient manner.
I tend to not run git locally, but prefer to run it on my source on the remote environment. This is mostly because I'm not wanting to use the native Mac OS userland.
I do not run tests locally, that's very much the intention.
I don't have a link to an article handy. You already seem familiar with the VS Code tooling, so it's a good place to start.
I'm not a pedant about this. There are some rough edges, especially in the file sync'ing for the local editor, and integration with IDEs. But you can get most of the way there and be pretty happy.
edit...
When I was working on ChromeOS, the actual workflow was more like "host OS" -> "local VM" -> "remote VM". The Crostini environment itself runs in a local VM and container. So you would essentially be running an editor inside that local VM (I ran VSCode this way for a hot minute), and I was working with an sshfs mounted src directory from a remote VM. This was mostly because I was doing work against a dev environment that relied on a number of hosted services that were only accessible to the remote VM. The hoops we sometimes have to jump through...