_edited_edited.png)
Imagine an application being developed. A team of developers and testers working on developing the code, writing user stories, testing their code and analyzing the results. The source code being developed has to be shared among the team members as various features of the application will be integrated. One way is to share files and documents individually with the whole team, update them on the changes you have made and then work together to integrate the code at a source level. In large and complex projects it may take a long time to coordinate and integrate the whole team’s code. there may be errors, omissions and revisions in code that may not reflect. This led to the need for a version control system which provides a way to manage different versions of a collection of files at any given time. Git was initially designed and developed by Linus Torvalds. It is free open-source software that can be used for version control in a distributed environment.
Source:https://github.com/git
Types of Version Control Systems
There are two types of version control systems:
Centralised Version Control System (CVCS)
CVCS uses a central server to store all files and allows for teams to coordinate various versions of their work. Teams have to be connected on the web to share files but a major challenge of this system is the fallibility of its central server. If the central server fails due to network-related or outage issues, the whole system grinds to a halt. Without comprehensive backup at a local level, it may not be possible for a team to access their project files also.
Distributed Version Control System (DVCS)
In DVCS there is a central repository, and every contributor has a local copy or clone of the main repository on their local system. So, everyone maintains a local repository of their own which contains all the files and metadata present in the main repository. Every checkout is a full backup of the repository. The client needs to push the changes to the branch which will then be pushed to the central repository.
Centralised Version Control System | Distributed Version Control System |
In CVCS, a client needs to get the local copy of source from the server, make the changes and commit those changes to the central server. | In DVCS, each user can have a local repository and have a complete history of the code. The user needs to push the changes to the specific branch which are then pushed to the central repository. |
CVCS system is easier to set up and adopt. | It is slightly more complex as there are multiple commands to be used for handling different types of situations while pushing, pulling and merging the code. |
Working on branches is bit complex in CVCS as developers often face conflict in merging. | Working on branches is easier in DVCS as it provides ways to resolve conflict. |
Does not provide offline access and is a bit slower. | Works fine on offline mode as the user has a copy of the repository on the local machine and works faster. |
It is difficult to carry out code completion in case system is down or there are network issues. | If server is down, work can be done using local versions on the local machines. |
How does Git work
Every local repository in Git has a working tree. There are files in the working tree which may be new or revisions of the original files. The user is authorized to change, create or delete these files. After making changes to the files present in git, the user has two options. One, to push these changes to the main branch. Second, maintain the revised version or revert to the original version in the local git itself. Suppose the user decides to make changes in their working directory and update those changes in the main branch, the following process needs to be followed:
Terminologies used in Git
Push—Used to upload the local repository content to a remote repository.
Pull—Used to fetch content from the remote repository and update the local repository to match that content.
Modified—Modified means that changes have been made to the file but the file has not yet been committed to the database yet.
Staged—Staging is one step before the commit process. It means that there is a modified file ready to go into the next commit snapshot.
Committed—Committed means that the data is safely stored in the local database.
Clone—It creates the instance of the repository. It checks out the working copy and mirrors the complete repository.
Branch—A branch is a pathway in which the user is currently working. The user can work on, let’s say, a dev branch and push the changes to the main branch. The user can decide when to merge the changes to the main branch.
Head—It is a reference used to point to the currently checked-out branch.
Repository—It refers to the history, different versions of the files over time and all the branches and tags. in Git each copy of the repository is a complete repository.
Revision—Represents a version of the source code.
Tag—It points to a commit which uniquely identifies a version of the Git repository.
URL—A URL in Git represents the location of the repository.
Working tree—Contains the set of working files for the repository.
Example of a Git branch
How to install and configure Git
We can download Git from the official website and install the required version based on our operating system. To verify that Git is installed properly, go to the command line and run this command.
Once Git is installed, the next step is to set your username and password.
git config –global user.name “git_username”
git config –global user.email “email_address”
Create a local directory using the command mkdir testing
Initialise the directory using the command git init
Goto testing folder and create a simple text file called demo1.txt
Go to gitbash and check the status by using git status
Add the text file to the current working directory using git add demo1.txt
Make a commit using the command git commit -m “Committing demo1.txt file”
Create an account on Github and then create a new repository called testing_repo
Copy the link of this remote repository, we will use it to link it to our local repository
Go back to git bash and link the remote and local repository using the command git remote add origin <link>
Go to testing_repo in Github and you can see the demo1.txt file there.
List of commonly-used Git commands
The following is the list of some useful git commands I came across while working with my team:
Go to project folder
CD [project path]
To see status of all files
git status
To add file
git add [filepath]
To commit changes
git commit -m"Message"
create new branch
git branch [branch name]
switch to branch
git checkout [branch name]
To fetch all branches from remote origin
git fetch --all
To see all branches at your machine
git branch -a
to reset all local changes
git reset --all
To hard reset files to Head (to be used judiciously)
git reset --hard head
Create new branch from remote origin
git checkout -b [branch1] origin/[branch2]
To pull a file
git pull
This command puts all your local changes first
git pull --rebase
force to switch branch
git checkout -f staging
To merge branches
git merge [your local branch name]
To restore deleted file
git checkout head [file path]
To push new local branch to server
git push -u origin head
Remove folder forcefully
git rm -r -f test-output/*
To revert changes made to your working copy
git checkout [filepath]
To make a copy of your changes
git stash
To get that copy back
git stash pop
replace file with origin branch
git checkout origin/dev
Conclusion
Being open source, Git is freely available to download and use over the internet. As most of the operations are performed locally, there is immense benefit in terms of speed. Though Git mirrors the entire repository, the size of the data on the client side is small. As multiple copies of the data are available on local machines, there is an assured backup of the code at the repository level. The measure of security provided by Git is quite strong as it uses a cryptographic hash function called secure hash function to name and identify objects in its database. The biggest benefit of Git is its ease of usage in adding files, making changes, removing files, pulling files and staging changes.