Today we will be learning about Git. but before that, let us get a bit familiar with version control tools. and understand how and where Git fits in there. We recommend our user to go through below blogs before proceeding forth.
What is Version Control?
The primary use of Version control is **Tracking changes**
A version control system is mostly based around one concept which is tracking changes that happen within directories or files. Depending on the version control system, this could vary from knowing a file changed to knowing specific characters or bytes in a file that have changed.
In most cases, you specify a directory or set of files that should have their changes tracked by version control. This can happen by checking out (or cloning) a repository from a host, or by telling the software which of your files you wish to have under version control.
The set of files or directories that are under version control is more commonly called a repository.
As you make changes, it will track each change behind the scenes. The process will be transparent to you until you are ready to commit those changes.
Types of version control systems
Current available version control systems can be classified into three main categories:
- Local VCS
- Centralized VCS
- Distributed VCS
Let’s learn more about them in details below.
Such kind of VCS normally resides only on the local machine of a developer. This system only helps in tracking changes made by the developer in his own machine. Such changes are difficult to share outside of his machine in a “VCS” format (meaning change history, version numbers etc.).
This kind of VCS serves very little purpose and not usable in teams whose size is >1 member.
Centralized version control
Another popular version control system, Subversion, is a centralized version control system.
Centralized version control systems are based on the idea that there is a single “central” copy of your project somewhere (probably on a server), and programmers will “commit” their changes to this central copy.
“Committing” a change simply means recording the change in the central system. Other programmers can then see this change. They can also pull down the change, and the version control tool will automatically update the contents of any files that were changed.
A Typical Centralized Version Control Workflow
When you’re working with a centralized version control system, your workflow for adding a new feature or fixing a bug in your project will usually look something like this:
- You Pull.
- Make changes
Distributed Version control
In distributed version control, each user gets his or her own repository and working copy. After you commit, others have no access to your changes until you push your changes to the central repository. When you update, you do not get others’ changes unless you have first pulled those changes into your repository. For others to see your changes, 4 things must happen:
- You commit
- You push
- They pull
- They update
Notice that the commit and update command only move changes between the working copy and the local repository, without affecting any other repository. By contrast, the push and pull commands move changes between the local repository and the central repository, without affecting your working copy.
Now that we are well aware of Version control concepts, let us get into Git.
Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.
As per creator of Git:
Git is easy to learn and has a tiny footprint with lightning fast performance. It outclasses SCM tools like Subversion, CVS, Perforce, and ClearCase with features like cheap local branching, convenient staging areas, and multiple workflows.
Git was created by Linus Torvalds in 2005 for development of the Linux kernel, with other kernel developers contributing to its initial development
Features of Git
we have heard a lot about Git till now. Let’s dig a bit deeper and understand how it is beneficial and different when compared with the competition
- Economical: Git is Free to use and modify.
- Open Source: Git is released under the GNU GPL2.0, which is an open source license and guarantees you freedom to share and change free software to make sure the software is free for all its users.
- Small and Fast: With Git, nearly all operations are performed locally, giving it a huge speed advantage by cutting down on any client-server communication. Git is written in C, which reduces the overhead of runtimes associated with higher-level languages.
- Distributed: As we have discussed before, Git is a distributed VCS. Distribution of repositories also ensures lots of redundant backups, which can come handy to restore in cases of disasters.
- Quick Branching: Create as many branches as you want, as frequently as you want, and share them with as many people as you want and Git won’t break a sweat.
- Adaptable Workflow: you can choose whichever workflow as you want. SVN Style? No Problem. Collaborative? You have it.
Git in DevOps
Remember that the development related problems which we discussed in our very first blog. Git plays a big role in solving the majority of problems. Git provides all the Distributed VCS facilities to the user that was mentioned earlier. Git repositories are very easy to find and access.
With Git, it becomes easier to
- Collaborate with developer team members and partners
- Track changes to the codebase.
- Restore an older version of a document/code in case of a mishap.
- Enable Continuous integration with Jenkins, any new change in the codebase can trigger a build in Jenkins and that can be used to quality check the changes.
- Backup the codebase with history.
For further updates, keep visiting www.acadgild.com