Version Control System

Version Control System: This is a system that accurately records changes to a file or set of files over time so that you can retrieve or recall specific versions later. Taking for example, software source code as the files being version controlled. Also Version Control System (VCS) can also be said to be root or source control systems used to track changes to software development projects, it allows the team members to change and collaborate on the same files. VCS gives room for software developers to work simultaneously on code and isolate their own work through branches that keep code changes protected from the changes in other branches, developers can merge codes together if and when ready. Developers can automatically track their work, view history of all changes effect and revert to previous versions of software when needed. Repository “repo” is where all the branches and codes changes are kept.

Team of software developers use version control systems to streamline the development process manage code for multiple projects and maintain a history of code changes. Version Control Systems is the appropriate tool needed for large, fast-changing projects with many authors to track changes and avoid general chaos. A good VCS does the following:

  • Track Changes. As files are updated, you can leave messages explaining why the change happened (stored in the VCS, not the file). This makes it easy to see how a file is evolving over time, and why.
  • Backup and Restore. Files are saved as they are edited, and you can jump to any moment in time. Example is to retrieve that file as it was on Aug 6, 2016.
  • Synchronization. Allow developers to share files and stay up-to-date with the latest version.
  • Short-term undo. It is well understood as in when you throw away your changes and go back to the “last known good” version in the database.
  • Long-term undo. Sometimes we mess up bad. Suppose you made a change a year ago, and it had a bug. Jump back to the old version, and see what change was made that day.
  • Track Ownership. A VCS tags every change with the name of the person who made it for proper and adequate retrieval or recalling .
  • Branching and merging. A larger sandbox. You can branch a copy of your code into a separate area and modify it in isolation (tracking changes separately). Later, you can merge your work back into the common area.

Basic Setup

  • Repository (repo): The database storing the files.
  • Server: The computer storing the repo.
  • Client: The computer connecting to the repo.
  • Working Copy: Your local directory of files, where you make changes.
  • Trunk/Main: The primary location for code in the repo

Basic Actions

  • 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.
  • Check out: Download a file from the repo.
  • Check in: Upload a file to the repository (if it has changed). The file gets a new revision number, and people can “check out” the latest one.
  • Checking Message: A short message describing what was changed.
  • Change log/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.

Advanced Actions

  • Branch: Create a separate copy of a file/folder for private use (bug fixing, testing, etc). Branch is both a verb (“branch the code”) and a noun (“Which branch is it in?”).
  • Diff/Change/Delta: Finding the differences between two files. Useful for seeing what changed between revisions.
  • Merge (or patch): Apply the changes from one file to another, to bring it up-to-date. For example, you can merge features from one branch into another.
  • 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.
  • Check out for edit: Checking out an “editable” version of a file. Some VCS have editable files by default, others require an explicit command.

For clarity: a typical scenario goes like this:

Afeez adds a file (list.txt) to the repository. He checks it out, makes a change (puts “gari” on the list), and checks it back in with a checking message (“Added required item.”). The next morning, Davis updates his local working set and sees the latest revision of list.txt, which contains “gari”. He can browse the change log or diff to see that Davis put “gari” the day before.