Version control (VC) is a library and time vault for digital assets. For a development team, its central job is to keep different versions of source code available so people can work in parallel without reshaping their development environments for each release. The principle applies beyond code: document tools can also retain edits. section 9.3
Fix production without releasing unfinished work
Suppose a team is partway through a major new version when a bug appears in production. The fix needs to start from the code actually running in production, without unfinished features mixed in. A suitable branching strategy lets the team maintain parallel development streams rather than coordinating every change around one release schedule. section 9.3 section 9.9
A directory of old releases or an occasional zip file is not a substitute for a working version-control practice. But an inherited system should not be replaced merely because it is unfamiliar. Investigate what it does, then make a change for a concrete reason. One team moved from a home-built zip-based substitute to Git so developers could use the tooling built into their IDEs; the transition did not need to become a public critique of its predecessor. section 9.3 section 2.4.1
Version control also creates a security consideration: credentials committed with code may reach unintended places, including code-quality tools that copy code for analysis. Some versioning tools, such as GitHub, perform basic checks and send alerts, but those checks should not be mistaken for a reason to commit credentials. section 12.4.4
To assess the practice across a team, ask:
- Does everyone understand why version control matters and use it as part of normal development? section 9.10
- Can the team work on a production fix while new development continues, without unfinished work entering the fix? section 9.3 section 9.9
- Are release and rollback processes repeatable, rather than dependent on one person or machine? section 9.10
