What a Version Control Process Has to Prevent
A version control process exists to answer one question: which file is the current one. Without it, a team ends up with three documents named final, held in two places, and the person who edits the wrong one discovers it after the work is done.
Every rule in a version process is downstream of that single question, which is why elaborate schemes fail and short ones survive. A team will follow four rules and will not follow eleven, so the design constraint is memorability rather than completeness. Excluded on purpose is anything requiring software: branching, merging, and repository workflows solve a different problem for a different audience and will end the video for this one.
The template sets it out in six scenes: one on the cost of not knowing which file is current, one on choosing a single storage location, one on a naming rule short enough to remember, one on version numbering and when a number changes, one on naming an owner per document, and one on archiving rather than deleting.
