Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
Atlas7514yMy 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...
atheist22304yMost 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.
LMagnus21674yWe 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.
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