There's no reason you can't make quick updates with version control. You'll each have a copy of the whole site (maybe with test databases) on your dev machines, and should be able to make the update, test it on your dev machine, then commit the changes to the repository.
What one of my friends says is that he usually makes some change directly on the code on the server, click CTRL-S and I can just refresh the page to see what he did.
With Git, for example, you modify the code on your machine, then save it, that you have to commit and push. Or am I wrong?
You're correct. But you should be able to test the code on your machine and make sure it's correct before committing it.
Your development machine should be able to run the same code as your server.
Making changes to the public site is a very bad practice. What if your code has errors in it?
Version control also keeps everyone up to date. Before making a change to the site you'll download the most up to date version from the repository, that way your local copy has everyones changes, with comments about what they've done.
Of course I'm not thinking about making changes to the public site. At the moment there is no public site, so I'm just thinking about a good development practice. I think that when the site will be public we may have a development copy of it on the server itself. I think we need to try it in practice, because we also have many doubts about resolving conflicts and merging.
It's simple. Use version control (I use git) and a VPN, where your friend can connect to your local webserver running your working copy to see your current state, but the live server stays clean and can be updated from git later.
There's no reason you can't make quick updates with version control. You'll each have a copy of the whole site (maybe with test databases) on your dev machines, and should be able to make the update, test it on your dev machine, then commit the changes to the repository.