Version Control Systems / Source code management (SCM)/Software

configuration management(SCM):

Version Control System:

The process of monitoring and managing changes to software code is known as version control,
also sometimes referred to as revision control or source control systems
Why Version Control System / Benefits of Version Control Systems:
1) We can maintain different versions and we can choose any version based on client
requirements.
2) With every version / commit we can maintain metadata like commit message
who did changes
when he did the change
what changes he did
3) Developers can share the code to the peer developers in a very easy way.
4) Multiple developers can work in collaborative way
5) It enables Parallel development.
6) We can provide access control like who can read code or who can modify code
7) If something goes wrong, you can revert to previous stable versions of the code,
ensuring that mistakes don’t have lasting negative impacts
Version Control System Terminology:
Working Directory: Where developers are required to create/modify files. Here version control
is not applicable. Here we won't use the word like version-1, version-2 etc
Repository: Where we have to store files and metadata. Here version control is applicable.
Here we can talk about versions like version-1, version-2 etc
Commit: The process of sending files from the working directory to the repository.
Checkout: The process of sending files from repository to working directory.
Types of Version Control Systems:
There are 2 types of Version Control Systems
1) Centralized Version Control System
2) De Centralized / Distributed Version Control System
Centralized Version Control System
The name itself indicates that this type contains only one central repository and every developer
should be connected to that repository. The total project code will be stored in the central
repository. If 4 developers are there, still we have only one repository.
Example: CVS, SVN, Perforce, TFS, Clearcase etc
Drawbacks:
1) Central Repository is the only place where everything is stored, which causes a single point
of failure. If something goes wrong to the central repository then recovery is very difficult.
2) All commit and checkout operations should be performed by connecting to the central
repository via network. If network outage, then no version control to the developer. i.e in this
type, developer work space and remote repository server should be connected always.
3) All commit and checkout operations should be performed by connecting to the central
repository via network and hence these operations will become slow, which causes performance
issues.
4) Organization of the central repository is very complex if the number of developers and files
increases.
Distributed Version Control Systems
The name itself indicates that the repository is distributed and every developer's workspace
contains a local copy of the repository. There is no question of a central repository.
1) The checkout and commit operations will be performed locally. Hence performance is more.
2) To perform checkout and commit operations, the network is not required. Hence if there is
any network outage, still version control is applicable.
3) If something goes wrong in any repository there is a chance to recover. There is no question
of a single point of failure.
4) To perform push and pull operations the network must be required, but these operations are
not the most common operations and we are performing very rarely.
Tools: Git, Mercurial, Fossil

Note:
1) commit and checkout operations will be performed between workspace and repository.
work space —>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
Remote Repository Server is not Central 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 remote repositories and these will be
performed on local repositories only.
3) The main job of remote repositories is just to share our work to peer developers.
4) High availability, Speed and there is no single point of failure are the main reasons for the
popularity of this model.
Example Tools or server :
Github, Gitlab, bitBucket, cloud platforms
What is GIT:
1. Git is a Distributed Version Control System Tool.
2. Git is not acronym and hence no expansion.But most of the people abbreviated as
"Global Information Tracker''.
3. GIT is developed by Linus(lai-nuhs taw vldz) Torvalds(Finnish software engineer), who
also developed Linux Kernel.
Features of GIT:
Distributed:
1. 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.
2. All operations will be performed locally, and hence performance is high when compared with
other VCSs. i.e it is very speed
3. Most of the operations are local. Hence we can work offline most of the time.
4. There is no single point failure as Every Developer has his own local repository.
5. It enables parallel development & automatic-backups.
Staging Area:
1 It is also known as the index area. There is a logical layer/virtual layer in git between working
directory and local repository.
2. Working Directory Staging Area Local Repository
3. 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.
4. This staging area is helpful to double check/cross-check our changes before commit.
5. This type of layer is not available in other Version Control System Tools like CVS, SVN etc
6. Git stores files in the 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 commit.
Eg: If a sample repository takes around 12 GB space in SVN where as in GIT it takes hardly
420 MB.
Hence Staging Area is the most important Strength of GIT.

Branching and Merging:

1. We can create and work on multiple branches simultaneously and all these branches are
isolated from each other. It enables multiple workflows.
2. We can merge multiple branches into a single branch. We can commit branch wise also.
3. 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.
4. Freeware and Open Source
5. It provides support for multiple platforms.

GIT Architecture:

GIt contains 2 types of repositories:

1) Local Repository
2) Remote Repository
❖ For every developer, a separate local repository is available. Developer can perform all
checkout and commit operations wrt local repository only.
❖ To perform commit operation, first he has to add files to staging area by using git add
command, and then he has to commit those changes to the local repository by using git
commit command. Hence commit in 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 to the peer developers then he has to push his
local repository to the remote repository by using git push command.
 ❖ Remote repository contains total project code, which can be accessible by all developers.
New developer can get local repository by cloning 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
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

Every file in GIT is in one of the following states:
1) Untracked:
The files which are newly created in working directory and git does not aware of these
files are said to be in an untracked state.
2) Staged:
The files which are added to the staging area are said to be in 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 it is modified in working directory is said to
be in a Modified State.

Example-1 To Understand Working Directory, Staging Area and Local Repository

1) Creating workspace
2) git initialization
3) Creating files with some content in the working directory
4) Adding these files to staging area
5) Git Configurations before first commit
6) Commit those changes to local repository

First create directories

❖ Now cse directory acts as a working directory. We have to request git, to provide
version control for this directory. For this we have to use the git init command.
 git init
❖ Once we create a workspace, if we want version control, then we require a local
repository. To create that local repository we have to use the git init command.
❖ .git is an empty repository, which is a hidden directory.

Note:
1) If our working directory contains any files, then these files won't be added to the local
repository by default, we have to add explicitly.
2) If our working directory already contains local repository(.git), still if we call git init
command, then there is no impact.
Creating Files with some Content and adding to staging Area and then commit:
 git status
It shows the current status of all files in each area, like which files are untracked, which are
modified, which are staged etc.
We can get concise information by using -s option.
Syntax: git status -s

Create a.txt and b.txt with some content

* After writing the content, press ctrl + D to get back to the command prompt.
 git add
To add files from the working directory to the staging area for tracking/commiting purposes, we
have to use the git add command.
To add all files present in current working directory
git add .
To add one or more specified files
git add a.txt
git add a.txt b.txt
Even we can use pattern also
git add *.txt
git add *.java
 git config
Git Configurations before 1st Commit:
Before the first commit, we have to configure username and mail id, so that git can use this
information in the commit records. We can perform these configurations with the following
commands.

global means these configurations are applicable for all repositories created by git. If we are not
using global then it is applicable only for the current repository.
We can change user name and mail id with the same commands
 git commit
If we want to commit staged changes, then we have to use the git commit command. For every
commit, a unique commit id will be generated. It is of 40-length hexadecimal string.
While using git commit command, commit message is mandatory.
 git log
It shows the history of all commits.
It provides commit id, author name,maild , timestamp and commit message.

git log file1.txt

Gives information of a Particular File.
git log --oneline
If we want concise output then we should go for the --oneline option.
git log --author shows commits based on Author.
Example: git log –author=Deepak

Suppose If we modify the File Content in working Directory:

Adding these modified Files to the staging Area and then commit:

We can combine above two commands into a single command

git commit -a -m "Both files modified"
git ls-files:
This command will list out all files which are tracked by git.

ls:
This command will list out all files present in workspace
 git diff command
It is a very common requirement to find differences between the content of a particular
file or all files.
1) Between working directory and staging area
2) Between working directory and last commit
3) Between staged area and last commit
4) Between working directory and a particular commit
5) Between staged area and a particular commit
6) Between two specific commits
For this we are required to use the git diff command. diff means difference
Example:
Create file1.txt file2.txt and add some content.
Type vim file.txt in command type
After executing the above command,the Text editor will open.
To insert data, type i in the keyword .
Enter the data you want to.
Press esc and type :wq(in editor itself) to come out of the vim file

file1.txt
First line in file1.txt
Second line in file1.txt

file2.txt
First line in file2.txt
Second line in file2.txt

Save the above files , add to staging area and commit

Again open file1.txt, file2.txt and add 2 more lines .
file1.txt
First line in file1.txt
Second line in file1.txt
Third line in file1.txt
Fourth line in file1.txt

file2.txt
First line in file2.txt
Second line in file2.txt
Third line in file2.txt
Fourth line in file2.txt
Now commit both files i.e 2 files contain 4 lines of content.
Now add one line to the file1.txt

file1.txt
First line in file1.txt
Second line in file1.txt
Third line in file1.txt
Fourth line in file1.txt
Fifth line in file1.txt

We are adding file1.txt to staging area

git add file1.txt

Again we add a new line in file1.txt of working directory

file1.txt
First line in file1.txt
Second line in file1.txt
Third line in file1.txt
Fourth line in file1.txt
Fifth line in file1.txt
sixth line in file1.txt

1. To see the difference in File Content between Working Directory and staging Area

diff --git a/file1.txt b/file1.txt

a/file1.txt means source copy which means staging area
b/file1.txt means destination copy which means working directory copy

index 0e17c9d..e3e329f 100644

0e17c9d hash of source file content
e3e329f hash of destination file content
100644 git file mode
First 3 characters(100) represent the type of file. 100 means ASCII text file.
Next 3 characters represents the file permissions. 644 rw-r--r--

--- a/file1.txt
--- means missing lines in staged copy

+++ b/file1.txt
+++ means new lines added in working directory version
@@ -3,3 +3,4 @@
-3,3
- means source version from 3rd line onwards total 3 lines
+3,4
+ means destination version from 3rd line onwards total 4 lines
If any line prefixed with space means it is unchanged.
If any line prefixed with + means it is added in destination copy.
If any line prefixed with - means it is removed in destination copy.

@@ -3,3 +3,4 @@
 Second line in file1.txt
Third line in file1.txt
Fourth line in file1.txt
Fifth line in file1.txt
+sixth line in file1.txt
Clear indication that one line added in the working directory copy when compared with staged
copy.
+sixth line in file1.txt
2. To see the difference in File Content between Working Directory and Last Commit
The last commit can be referenced by HEAD.
git diff HEAD file1.txt
It shows the differences between working copy and last commit copy.

3. To see the difference in File Content between staged Copy and Last Commit
We have to use --staged option or --cached option.
git diff --staged HEAD file1.txt
It shows the differences between staged copy and last commit copy.
Here HEAD is optional. Hence the following 2 commands will produce same output
git diff --staged HEAD file1.txt
git diff --staged file1.txt

4. To see the difference in File Content between specific Commit and Working Directory
Copy.
git diff 7chracters_of_specified_commitid filename
$ git log --oneline
042b184 (HEAD -> master) 2 files added and each file contains 4 lines
9b64469 2 files added and each file contains 2 lines

Summary:
git diff
Shows the differences in the content of working directory, staging area and local repository. we
can use in the following ways
1) git diff file1.txt To compare working directory copy with staged copy
2) git diff HEAD file1.txt To compare working directory copy with last commit copy
3) git diff --staged file1.txt
git diff --cached file1.txt
git diff --staged HEAD file1.txt git diff --cached HEAD file1.txt
To compare staged copy with last commit copy
4) git diff <commit id>file1.txt To compare working directory copy with the specified commit
copy.
5) git diff --staged <commit id>file1.txt To compare staged copy with the specified commit
copy.
6) git diff <source commit id> <destination commit id>file1.txt To compare content in the
file between two commits
7) git diff HEAD HEAD~1 file1.txt To compare content in the file between last commit and
last but one commit.
8) git diff <source commit id> <destination commit id> : To compare content of all files
between two commits.
9) git diff master test It shows all differences between master branch and test branch
10) git diff master origin/master It shows all differences between master branch in local
repository and master branch in remote repository.
 git restore command
This command can be used to undo the effects of git add and unstage changes you have
previously added to the Staging Area.
This restore command can also be used to discard local changes in a file, thereby restoring its
last committed state.
Example:

Open a.txt file and add one line

Open Git Bash , add the file to the staging area and see the status.
git restore –staged:
Removes the file from the Staging Area, but leaves its actual modifications untouched

git restore:
Suppose you made changes to a file named example.txt, but now you want to discard those
changes.
Open b.txt , add second line,add to the staging area and then commit
git restore --source:
This command is specifically designed to restore files in your working directory from a
specific commit.

Difference between git restore and git checkout:

git restore --source:
Example:
git restore --source=fc5ae8c a.txt
This command restores the example.txt file from commit fc5ae8c without affecting your
current branch or the HEAD pointer.
Use git restore --source if we want to restore files from a specific commit or branch. It's part of
the modern Git workflow, designed to make actions more intuitive.
git checkout:
Example:
git checkout fc5ae8c -- a.txt
This command does a similar thing by restoring example.txt from commit fc5ae8c, but the git
checkout command can also be used to switch branches, which might cause confusion.
Use git checkout if you need to switch branches or restore files with an older Git version, but
be cautious of its dual functionality.
Removing Files by using git rm Command
It is a very common requirement to remove files from the working directory and staging area.
For these removals we can use the following commands
1) To Remove Files from Working Directory and staging Area (git rm)
git rm file1.txt
file1.txt will be removed from staging area and from working directory
2) git rm -r . It will remove all files from the staging area and working directory.
3) To Remove Files Only from staging Area (git rm --cached)
git rm --cached file4.txt
file4.txt will be removed only from staging area but not from working directory
4) To Remove Files Only from Working Directory (rm Command)
rm file1.txt