The aim of this article is to further simplify the terms associated with Version Control, so that everybody can get a clear understanding of it.
Checkins and Checkouts
Checking out is the process of downloading the file from repo in-order to make some edits to its content.
Checking in means uploading a file to the repository after making a change to the original or previous version.
We can “branch the code” in order to create a separate folder / parallel path to the main trunk which can be used for specific improvements, bug fixing, testing etc…
Updating the content of one branch using a version in another branch is called merging.
Even though the below diagram may seem really simple, merging is generally harder than branching as we need to figure out which branch to merge from and how.
Below are some other terms related to Version Control;
- Repository: The database storing the files.
- Server: The computer storing the repo.
- Client: The computer connecting to the repo.
- Trunk: The primary location for code in the repo. Think of code as a family tree — the trunk is the main line.
- Working Copy: Your local directory of files, where you make changes.
- Add: Put a file into the repo for the first time, i.e. begin tracking it with Version Control.
- Revision: What version a file is on (v1, v2, v3, etc.).
- Head: The latest revision in the repo.
- Checkin Message: A short message describing what was changed.
- Changelog/History: A list of changes made to a file since it was created.
- Update/Sync: Synchronize your files with the latest from the repository. This lets you grab the latest revisions of all files.
- Revert: Throw away your local changes and reload the latest version from the repository.
- Diff/Change/Delta: Finding the differences between two files. Useful for seeing what changed between revisions.
- Conflict: When pending changes to a file contradict each other (both changes cannot be applied).
- Resolve: Fixing the changes that contradict each other and checking in the correct version.
- Locking: Taking control of a file so nobody else can edit it until you unlock it. Some version control systems use this to avoid conflicts.
- Breaking the lock: Forcibly unlocking a file so you can edit it. It may be needed if someone locks a file and goes on vacation (or “calls in sick” the day Halo 3 comes out).
- Check out for edit: Checking out an “editable” version of a file. Some VCSes have editable files by default, others require an explicit command.