Introduction
Source code management (SCM) is an essential tool for software development teams to efficiently manage and collaborate on code. However, without proper SCM, teams may encounter several issues, such as conflicting code changes, lost code versions, and difficulty in reviewing and merging code.
To address these challenges, a source code management system provides a centralized platform for version control and collaboration. It allows developers to track changes made to the codebase, revert to previous versions if necessary, and collaborate on code changes through a review process. Additionally, SCM systems provide a way to manage multiple branches of code simultaneously, enabling teams to work on different features or bug fixes concurrently.
Types of source code management system
Centralized Version Control Systems (CVCS)
Distributed Version Control Systems (DVCS)
Hybrid Version Control Systems
Cloud-Based Version Control Systems
Source Code Collaboration
1.Centralized Version Control Systems (CVCS)
CVCS stands for Centralized Version Control System. In a CVCS, a single central server stores the code repository, and developers can check out and modify files locally. When a developer makes changes to the code, they check their changes back to the central repository. This allows other developers to access the latest version of the code and collaborate on the project.
This type of VCS is very easy to set up and use.
Eg: CVS, SVN, Perforce, TFS, ClearCase etc1.1Problems with Centralized VCSs:
1)Central Repository is the only place where everything is stored, which causes a single point of failure. If something goes wrong with the central repository then recovery is very difficult.
2) All commit and checkout operations should be performed by connecting to the central repository via a network. If network outage, then no version control for the developer. i.e in this type, the developer workspace and remote repository server should be connected always.
3) All commit and checkout operations should be performed by connecting to the central repository via the network hence these operations will become slow, which causes performance issues. No local operations and every version control operation should be remote operation.
4) Organization of the central repository is very complex if the number of developers and files increases. etc
To resolve this problem the Distributed version controll system intraduced.
2.1.Distributed Version Control Systems (DVCS)
In a DVCS, developers create their own local repositories and work on the code locally. This allows them to work offline and make changes to the code without needing to access a central server. When they are ready to share their changes, they can push their changes to a central repository or pull changes made by other developers.
DVCS systems typically include features for branching and merging code, access control to manage user permissions, and versioning of files. Because each developer has their own copy of the code, DVCS systems provide a higher level of flexibility and enable more complex workflows than CVCS systems. Examples of DVCS include Git, Mercurial, and Bazaar.
If 4 developers are there then 4 repositories will be there.
The checkout and commit operations will be performed locally. Hence the performance is more.
To perform checkout and commit operations network is not required. Hence if there is any network outage, still version control is applicable.
If something goes wrong with any repository there is a chance to recover. There is no question of a single point of failure.
To perform push and pull operations network must be required, but these operations are not the most common operations and we are performing them very rarely.
Note:
1) commit and checkout operations will be performed between workspace and repository.
workspace – commit --> Repository
Repository – checkout -->workspace
2) push and pull operations will be performed between repositories.
one repository ---push -->other repository
one repository <--pull----other repository
2.2Distributed VCS with Remote Repository
1) Every developer has his own local copy of the repository. It is not centralized and it is distributed only.
2) commit and checkout operations won't be performed on the remote repository and these will be performed on the local repository only.
The main job of a remote repository is just to share our work with peer developers. High availability, Speed and there no single point of failure are the main reasons for the popularity of this model.
GIT is an example of a local distributed version control system.
where GitHub is an example of a remote Distributed version control system.
Features and Architecture of GIT
What is GIT?:
✽ Git is Distributed Version Control System Tool.
✽ Git is not an acronym and hence no expansion. But most of the people abbreviated ✽ "Global Information Tracker".
✽ GIT is developed by Linus Torvalds(Finnish software engineer), who also developed Linux Kernel.
✽ Most companies like Microsoft, Facebook, Yahoo, LinkedIn, Intel use Git as Version Control System Tool.
Features of GIT:
Git is very popular because of the following features:
1) Distributed
Git is developed based on Distributed Version Control System Architecture. Because of Distributed Architecture, it has several advantages:
Every Developer has his own local repository. All the operations can be performed locally. Hence local repo and remote repo need not be connected always.
All operations will be performed locally, and hence performance is high when compared with other VCSs. i.e it is very speedy.
Most of the operations are local. Hence we can work offline most of the time.
There is no single-point failure as Every Developer has his own local repository.
It enables parallel development & automatic backups.
2) Staging Area:
It is also known as the index area.There is a logical layer/virtual layer in git between the working directory and the local repository.
Working Directory --> Staging Area --> Local Repository
We cannot commit the files of the working directory directly. First, we have to add to the staging area and then we have to commit.
This staging area is helpful to double-check/cross-check our changes before committing.
This type of layer is not available in other Version Control Systsem Tools like CVS, SVN etc
Git stores files in a repository in some hash form, which saves space.
GIT will use an internal snapshot mechanism for this. All these conversions and taking snapshots of our data will happen in the staging area before committing.
Eg: A sample repository takes around 12 GB of space in SVN whereas in GIT it takes hardly 420 MB.
Hence Staging Area is the most important Strength of GIT.
3) Branching and Merging:
We can create and work on multiple branches simultaneously and all these branches are isolated from each other. It enables multiple workflows.
We can merge multiple branches into a single branch. We can commit branch-wise also.
4. Moving files in GIT is very easy as GIT automatically tracks the moves. Whereas in other VCS we need to create a new file & then delete the old one.
5.Freeware and Open Source
6.It provides support for multiple platforms.
GIT Architecture:
GIt contains 2 types of repositories:
Local Repository
Remote Repository
For every developer, a separate local repository is available. The developer can perform all checkout and commit operations wrt the local repository only.
To perform the commit operation, first, he has to add files to the staging area by using the git add command. Then we have to commit those changes to the local repository by using git commit command. Hence commit to GIT is a 2-step process.
commit is applicable only for staging area files but not for working directory files. If the developer wants to share his work with the peer developers then he has to push his local repository to the remote repository by using the git push command.
The remote repository contains the total project code, which can be accessible by all developers. New developers can get the local repository by cloning the remote repository. For this, we have to use the git clone command.
A developer can get updates from the remote repository to the local repository by using the git pull command.
git add --> To add files from working directory to staging area.
git commit --> To commit changes from staging area to local repository.
git push --> To move files from local repository to remote repository.
git clone --> To create a new local repository from the remote repository.
git pull --> To get updated files from remote repository to local repository.
Life Cycle of File in GIT
1)Untracked:
The files which are newly created in the working directory and git does not aware of these files are said to be in the untracked state.
2) Staged:
✽ The files which are added to the staging area are said to be in the staged state.
✽ These files are ready for commit.
3) In Repository/ Committed:
Any file which is committed is said to be In Repository/Committed State.
4) Modified:
Any file which is already tracked by git, but is modified in the working directory is said to be in Modified State.
conclusion:
In this article, we learn about the types of the version control systems.
limitation of centralized version control system.
decentralize version control system.
feature about Git-Github DCVS system
life-cycle of Git
Architecture of Git