Skip to content

Latest commit

 

History

History
51 lines (36 loc) · 3.76 KB

index.md

File metadata and controls

51 lines (36 loc) · 3.76 KB

Introduction to version control systems

Let's see what we can do with VCS, and how it will benefit our developer skills.

What are Version Control Systems?

A version control system (VCS) is a piece of software that records files and the changes in those files so you can switch in between specific versions later. The collection of versions are saved in a place called repository so they are tracked into a captured snapshot at certain point in time.

Version control systems Source: Vogella

Simple: Think about VCSs as a software that tracks all the changes you make to certain group of files so you can revert any change at any time. No more files named: final-draft1-copy-this-is-final-now-correct-final-1

Version control concepts

Basic Setup

  • Repository (repo): The database storing the files.
  • Server: The computer storing the repo.
  • Client: The computer connecting to the repo.
  • Working Set/Working Copy: Your local directory of files, where you make changes.
  • Trunk/Main: The primary location for code in the repo. Think of code as a family tree — the trunk is the main line.

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.
  • 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.

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 (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.

And a typical scenario goes like this:

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

Source: Better explained