Version Control Basics

Version Control Basics

By Ifeanyi Omeata


Here are the basic Version Control topics:


  1. What is Version Control?
  2. Benefits of Version Control
  3. Committing
  4. Changesets
  5. Conflicts
  6. Diffing
  7. Branching
  8. Merging
  9. Centralized vs Decentralized VCS
  10. Centralized Version Control System
  11. Decentralized/Distributed Version Control System


1. What is Version Control?


A version control system is primarily concerned with one concept: tracking changes in directories or files. This could range from knowing a file has changed to knowing specific characters or bytes in a file have changed, depending on the version control system.

  • A repository is a collection of files or directories that are subject to version control.
  • Most of the time, you specify a directory or collection of files whose changes should be tracked by version control.
  • It will track each modification you make behind the scenes as you make them.
  • Until you are ready to commit to those modifications, the process will be transparent to you.
  • There are 2 main types of version control systems: Centralized and Decentralized.
  • There are 3 popular version control systems: Git, Mercurial and SubVersion.


2. Benefits of Version Control


  • File names and directory structures are consistent for all team members.
  • Changes are made with confidence, and even permit reverting when needed.
  • Reliance on source control as the communication medium for team.
  • Ease in deploying different versions of code to staging or production servers.
  • Understanding who made a change to code and when it happened.


3. Committing


  • Modification of code is automatically monitored while you work with your version-controlled files.
  • Modifying a file, removing a directory, creating a new file, relocating files, and just about anything else that can change the status of the file are all monitored.
  • Instead of logging each change separately, the version control system will wait for you to submit all of your changes as a single batch.
  • This combination of operations is referred to as a commit in version control.


4. Changesets


When a commit is made, the modifications are logged as a changeset and assigned a unique revision. Depending on the system, this revision could be in the form of an incremented number (1, 2, 3) or a unique hash.

  • Knowing a changeset's revision makes it simple to view or refer to it later.
  • A changeset will contain information on who made the change, when it was made, the files or directories that were affected, a note, and even the changes that occurred inside the files (lines of code).
  • Viewing previous revisions and changesets is a useful tool for seeing how your project has progressed and analyzing peers' code when it comes to cooperation.
  • Each revision and changeset in the repository has a formatted history (or log) that can be seen in each version control system.


5. Conflicts


It's critical that you have the most recent version as members of your team make modifications. Conflicts are less likely when you have the most recent version. It's as easy as pulling or updating from another computer to get the most recent updates from a repository (usually a hosted or centralized server).

  • Only the changes since your last request are downloaded when you request an update or pull.
  • A conflict occurs If your changes are sufficiently similar to those made by another team member that the version control system can't tell which is the authoritative and right change.
  • In that case, the version control system will show you the differences between the conflicting versions so you can decide which one to use.
  • You can manually merge the options by editing the files, or you can let one revision triumph over the other.
  • You might want to work with the individual who made the other commit to ensure you don't undo their hard work!


6. Diffing


It's occasionally beneficial to see what changed between revisions because each commit is documented as a modification to a file or collection of files and folders.

  • For example, if a recent deployment of your website is faulty and you've limited the problem down to a certain file, the best course of action is to discover what just changed in that file.
  • You may compare two files or even a series of files to observe what lines of code changed, when they changed, and who changed them by reading a diff.
  • Most version control technologies allow you to compare two consecutive revisions, as well as two revisions from any point in time.


7. Branching


There are times when you want to try something new or commit changes to the repo that might break something else in your code (like working on a new feature). You can construct a branch instead of directly committing this code to the main set of files (typically referred to as trunk or master).

  • A branch allows you to make a copy (or snapshot) of the repository that you may work on in parallel with the main set without affecting it.
  • While you work, you can continue to commit fresh modifications to the branch while others commit to the trunk or master without the changes interfering.


8. Merging


Once you've become comfortable with the branch code, you'll want to merge it back into trunk or master. Merging is the process of doing that.

  • The version control system understands how each file has been edited because it has recorded every modification so far.
  • The version control tool will attempt to seamlessly merge each file and line of code by merging the branch with the trunk or master (or even another branch).
  • When a branch is merged, the trunk or master is updated with the latest files.


9. Centralized vs Decentralized VCS


There are two main types or categories of Version Control Systems:

  • Centralized VCS
  • Decentralized (Distributed) VCS


The three most popular version control systems are classified under Centralized and Decentralized VCS categories:

  • Git
  • Mercurial and
  • SubVersion


10. Centralized Version Control System


SubVersion open source Apache software project is the most used centralized version control system at the time of this writing. It was founded in 2000 by CollabNet, Inc., and have seen incredible success over the past decade.

  • A centralized system's main premise is that it operates in a client-server relationship.
  • The repository is centrally positioned and accessible to a large number of clients.
  • It works similarly to FTP, in that you use an FTP client to connect to an FTP server.
  • This central repository must be responsible for sending and receiving all updates, users, commits, and information.

image.png


PROs:
The following are the main advantages of Subversion:

  • It is easy to understand and use.
  • You have more control over who sees what and when they see it, since it is viewed from one source.
  • GUI Clients and integrated development environments (IDE) are effectively provided, which have been used and tested over a long period of time.


CONs:

  • Access to the server is required.
  • It's more difficult to keep track of a server and it's backups.
  • Because every command communicates with the server, it may be slower.
  • The tools for branching and merging causes more conflicts.


11. Decentralized/Distributed Version Control System


Distributed systems are a more recent development. Each user under distributed version control has their own copy of the complete repository, including not only the files but also the history. Consider it a collection of individual repositories.

  • Even though the model is distributed, services such as Beanstalk are frequently utilized to reduce the technical hurdles of sharing updates.
  • Git and Mercurial are the two most popular distributed version control systems.

image.png


PROs:
The following are the main advantages of Git and Mercurial:

  • Change tracking is more robust and detailed, which causes fewer conflicts.
  • There is no need for a server because all actions, with the exception of sharing repositories, are performed locally (commit offline).
  • Because branching and merging are more trustworthy, they are employed more frequently.
  • It is faster.


CONs:
Git and Mercurial, on the other hand, have some disadvantages:

  • The distributed model is more difficult to understand.
  • Because it's new, there aren't as many GUI clients.
  • The revisions are not numbered sequentially, making them more difficult to reference.
  • It's easier to make mistakes until you are familiar with the model.

#End


Hope you enjoyed this! :) Follow me for more contents...


Get in Touch:
ifeanyiomeata.com

Youtube: youtube.com/c/IfeanyiOmeata
Linkedin: linkedin.com/in/omeatai
Twitter: twitter.com/iomeata
Github: github.com/omeatai
Stackoverflow: stackoverflow.com/users/2689166/omeatai
Hashnode: hashnode.com/@omeatai
Medium: medium.com/@omeatai
© 2021**