GIT Version Control System
Version control system (VCS) is a piece of software that can track the changes of file or a set of files over the time. In case of that if you want to recall the previous version, you can call that specific version securely without affecting the current version of the file. These system enable you to work individually as well as the team. The version control system is a collection of software tools that help a team to manage changes in a source code. It uses a special kind of database to keep track of every modification to the code. It plays a major role in the software development. Software development without a version control system is like ride a boatwithout the safe equipment. It provides backup for uncertainty. Here are some advantage of virsion control system.
- Complete change history of the file Simultaneously working
- Branching and merging
- Traceability
There are three types of version control system.
- Localized version control system
- Centralized version cotrol system
- Distributed version control sysem
Localized version control system
It is a common approach as its inherited simplicity. But it has high posibility to getting errors.In this approach, you may forget which directory you’re in and accidentally write to the wrong file or copy over files you don’t want to. To overcome these issues, a local VCSs were introduced which contains a simple database with it.Such databases kept all the changes to files under revision control. A local version control system keeps local copies of the files. Major drawback is it has single point of failures.
Centralized version cotrol system
As the localized VCSs are fail to support colloboration amaong developera, a new VCS was developed as a Centralized VCS. These systems have a single server that contains the versioned files, and some clients to check out files from a central place. When compare with the local VCS, it has many benefits over the localized one.
- Administrators have control over other developers
- Same information are shared among the all memebers in the project
- Easy user interaction
Though it has many benifits, it also has same problem in the local VCS, as centralized Version Control System uses a central server to store all the database and team collaboration. But due to single point failure, which means the failure of the central server, developers do not prefer it.
Distributed Version Control System (DVCS)
To overcome the single point of failure issue, distributed VCS was introduced. In here user has a local copy of the repository and clients don’t just check out the latest snapshot of the files even they can fully mirror the repository. Local copy of the repository contains all the fies and metadata in the main repository.
DVCS allows automatic management branching and merging. It speeds up of most operations except pushing and pulling. DVCS enhances the ability to work offline and does not rely on a single location for backups. If one server is stop and others are still collabarate and then any of client repositories can be restored by that server. Another important thing is that every checkout is a full backup of all the data.
Git is the most popular version control system in the all over the world and it was introduced by the Linus Torvalds in 2005. It is a distributed VCS. GitHub, Bitbucket and GitLab are some of products that providing hosting services for the Git projects. To get better understanding about the git, you should have clear idea about the following terms.
Repository : It is a file storage space. There are two types of repository called Remote repository and the Local repository. Local repository is the repository which contains all the files in our local,physical mechine. Remote repository is the repository which we have created inside one of the above mentioned hosting service.
It is important to use a remote repository in order to be able to collaborate with other people as well as to backup our projects in case something happens to our laptop or computer.
Branch: A branch is a version of the repository that diverges from the main working project. A Git project can have more than one branch. We can perform many operations on Git branch-like rename, list, delete, etc.
//To list the available branch
$ git branch//Create new branch
$ git branch <branch name>//Delete the branch
$ git branch -d <branch name>
Checkout: In Git, the term checkout is used for the act of switching between different versions of a target entity. The git checkout command is used to switch between branches in a repository.
Master: Master is a naming convention for Git branch. It’s a default branch of Git. After cloning a project from a remote server, the resulting local repository contains only a single local branch. This branch is called a “master” branch.
Origin: In Git, “origin” is a reference to the remote repository from a project was initially cloned. Simply, it is used instead of that original repository URL to make referencing much easier.
Head: HEAD is the representation of the last commit in the current checkout branch. We can think of the head like a current branch. When you switch branches with git checkout, the HEAD revision changes, and points the new branch.
Pull and Pull Request: The term Pull is used to receive data from GitHub. It fetches and merges changes on the remote server to your working directory. Pull requests are a process for a developer to notify team members that they have completed a feature. It announces all the team members that they need to review the code and merge it into the master branch.
Stashing: Sometimes you want to switch the branches, but you are working on an incomplete part of your current project. You don’t want to make a commit of half-done work. Git stashing allows you to do so without committing the current branch.
Tag: ags are used to define which portions of a project’s Git history is most important. Often this is used to note point releases of a project. Tags can be added to the commit you are working with or added after-the-fact when needed. Light-weight tag and Annotated tag are the types of tags.
Git Workflow — Git Commands
Step 01 — Create a repository on the GitHub or any other host service. If you want to contribute to the existing repository, no need to follow this step. If that repository is owned by someone, you have to clone it to your local computer.
$ git clone <repository URL>Step 02 — Edit the file in the local computer and save them. After go to your local repository and then open the Git Bash. Else you can change the current working directory via the command line.
$ cd <path of the project folder>Step 03 — Initialize an empty git repository to the local repository.
$ git initStep 04 — You can avoid this step. But as a best practise introduce yourself to the git, providing username and email of the github account.
$ git config --global user.name "Enter your user name"
$ git config --global user.email <enter your github email>Step 05 — Next, tell Git to take a snapshot of the contents of all files under the current directory using “ add . “ and if you want to send a particular file then type the file name instead of “.” . In here file is send to the staging area.
$ git add .
$ git add <file name>Step 06 — Then permantly store the changes making a commit for your changes.
$ git commit -m " enter a commit message"Step 07 — Create the connection between the remote repository. In here you want the remote URL for that. (In the initial time)
$ git remote add origin <Remote repository URL>Step 08 — Push the changes in your local repository to the remote repository.
// push chnages to specific branch
$ git push origin your-branch //push to the main branch
$ git push origin main
Stay Safe & Learn New Things!!!
References:
