ICS 125: Version control

Software development is a process of constant change to a valuable asset
- Not all changes are good, sometimes you want to go back
- You need to see why changes were made, and who made them
- You will want to apply the same changes to multiple branches of development
Version control means:
- Keeping a history of all changes to all files
- Integrating the changes made by many developers
- Managing multiple branches of development
- Knowing with certainty the changes that have been put into a release
- Knowing with certainty that the code released is the same code that was tested
Also called: "configuration management", "CM", "SCM", "VC"
- Sometimes people include issue tracking and build systems in the term SCM
- Thinking more generally, CM for products may include both hardware and software assets

Server keeps history of changes on every file
- Each version of a file is numbered (e.g., 1.1, 1.2., 1.3) and can be tagged with a name (e.g., v1_0_0RC1)
- The "HEAD" version of a file is the latest version on the main branch of development, it is checked out by default
- A branch of development is a sequence of versions that is parallel to other versions in other branches
- A "diff" is the set of source code lines that changed between one version and another. A.k.a, changes, change-set, or patch.
- The commit log contains developer comments that explain each change
Developers use a client to check out a working copy, make changes, commit the changes
- A "check out" or "update" is downloading files from server to developer workstation
- A "check in" / "commit" is uploading files to the server
- A developer makes several related changes, test them, then commit them together
Conflicts may occur when two developers edit the same file at the same time
- Some changes can be automatically merged before the commit
- Other changes require one of the developers to manually resolve the conflict
- It is never the case that changes overwrite each other without any developer noticing