Hello guys, I've got a question. When you're working with someone in a project using a VCS, how do you go when implementing stuff? Do you create a new branch and then merge to master or do you tell to the other guy that you're going to do "this thing" so he doesn't do it or what? I've never collaborated with someone and I would like to have a little information about this topic. The things I've built have been all by myself so If some day I ever plan to work with someone else I rather know this stuff already.

My favourite quote: "a VCS does not replace communication" I personally have a local "temp" branch with my initials as branch-name which I push to the staging server (just for any purposes between different machines) but lock for everyone else. Working there and then mostly merging stuff from or to the "dev" branch. If nothing breaks there, those changes get merged to the master. The master has only merge-commits, no normal commits, and with every merge from the dev the version tag gets a +1 after the semver-model -position (x.x.x) depending on the scale of the changes. It will also help to google for "successful git branching model" - it really helped me to understand the concept of git...

Most of the colab vcs work I do is at work. The project is of a reasonable size where generally we agree on an API and then work on either side of it. So basically don't bother with branching unless we're really going to break something (rework). If API requirements change we sit a few meters away. Some people do work on branches, but tbh it's usually possible to do continuous integration.

We create a branch for each change request then merge back to main when development is complete. Then deploy from main.

We all work on the same branch so conflicts are caught early and prompt a discussion.

Horror time.
Google has all its code in one single repo, in one single branch, master. That's it. All of it.

There's like 70, 000 test cases to pass before you get to push though