Git is a version control system (VCS) created by Linus Torvalds in 2005 for development of the Linux kernel. Git used to track changes in computer files and coordinating work on those files among multiple people. It is primarily used for software development, but it can be used to keep track of changes in any files.
A staggering number of software projects rely on Git for version control, including commercial projects as well as open source. Developers who have worked with Git are well represented in the pool of available software development talent and it works well on a wide range of operating systems and IDEs.
The raw performance characteristics of Git are very strong when compared to many alternatives. Committing new changes, branching, merging and comparing past versions are all optimized for performance. The algorithms implemented inside Git take advantage of deep knowledge about common attributes of real source code file trees, how they are usually modified over time and what the access patterns are.
Unlike some version control software, Git is not fooled by the names of the files when determining what the storage and version history of the file tree should be, instead, Git focuses on the file content itself. After all, source code files are frequently renamed, split, and rearranged. The object format of Git's repository files uses a combination of delta encoding (storing content differences), compression and explicitly stores directory contents and version metadata objects.
Why version control software needed for development process?
Version control software allows you to have “versions” of a project, which show the changes that were made to the code over time, and allows you to backtrack if necessary and undo those changes. This ability alone – of being able to compare two versions or reverse changes, makes it fairly invaluable when working on larger projects.
You’ve probably even done this yourself at some point, saving out copies of a project at different points so you have a backup. In a version control system, just the changes would be saved – a patch file that could be applied to one version, in order to make it the same as the next version. With one developer, this is sufficient.
But what if you have more than one developer working on a project? That’s when the idea of a centralised version control server comes in. These have been the standard for a long time, whereby all versions are stored on a central server, and individual developers checkout and upload changes back to this server.
The benefits of a system like this is that multiple developers can make changes, and each change can then be attributed to a specific developer. On the downside, the fact that everything is stored on a remote database means no changes can be made when that server goes down; and if the central database is lost, each client only has the current version of whatever they were working on.
In these systems, clients don’t just check out the current version of the files and work from them – they mirror the entire version history. Each developer always has a complete copy of everything. A central server is still used, but should the worst happen, then everything can still be restored from any of the clients who have the latest versions.
Git specifically works by taking “snapshots” of files; if files remain unchanged in a particular version, it simply links to the previous files – this keeps everything fast and lean.
What is Github?
Github is both a remote server, a community of developers, and a graphical web interface for managing your Git project. It’s free to use for up to 5 public repositories – that is, when anyone can view or fork your code – with low cost plans for private projects.