By far the most widely used modern version control system in the world today is Git. Git is a mature and actively maintained open source project originally developed in 2005 by Linus Torvalds, the famous creator of the Linux operating system kernel. A staggering number of software projects rely on Git for version control, including commercial and open source projects. Developers who have worked with Git are well represented in the pool of software development talent available and it works well across a wide range of operating systems and IDEs (integrated development environments).
Having a distributed architecture, Git is an example of DVCS (hence the Distributed Version Control System). Instead of having a single place for the complete version history of the software as is common in once-popular version control systems like CVS or Subversion (aka SVN), in Git, each developer’s working copy of code is also a repository that can contain the complete history of all changes.
In addition to being distributed, Git has been designed with performance, security, and flexibility in mind.
The raw
performance characteristics of Git are very strong compared to many alternatives. Committing new changes, branching, merging, and comparing previous versions are optimized for performance. The algorithms implemented within Git leverage deep knowledge about the common attributes of actual source file trees, how they are generally modified over time, and what the access patterns are.
Unlike some version control programs, Git is not fooled by file names when determining what the storage and version history of the file tree should be, instead, Git focuses on the contents of the file itself. After all, source code files are frequently renamed, split, and reorganized. The object format of Git repository files uses a combination of delta encoding (storing content differences), compression, and explicitly stores directory content, and version metadata objects.
Distribution also enables significant performance benefits.
For example, suppose a developer, Alice, makes changes to the source code, adds a feature for the upcoming 2.0 release, and then commits those changes with descriptive messages. Then he works on a second role and also makes those changes. Naturally, these are stored as separate pieces of work in the version history. Alice then switches to the version 1.3 branch of the same software to fix a bug that affects only the previous version. The purpose of this is to allow Alice’s team to submit a bugfix version, version 1.3.1, before version 2.0 is ready. Alice can go back to the 2.0 branch to continue working on new features for 2.0 and all this can happen without any network access and is therefore fast and reliable. You could even do it on a plane. When she is ready to push all committed changes individually to the remote repository, Alice can “push” in a single command.
Security
Git has been designed with managed source code integrity as a top priority. The contents of the files, as well as the true relationships between files and directories, versions, tags and commits, all these objects in the Git repository are protected with a cryptographically secure hash algorithm called SHA1. This protects code and change history against accidental and malicious changes and ensures that the history is fully traceable.
With Git, you can be sure that you have an authentic content history of your source code.
Some other version control systems do not have protections against secret tampering at a later date. This can be a serious information security vulnerability for any organization that relies on software development.
One
of
Git’s key design goals is flexibility. Git is flexible in several ways: in supporting various types of nonlinear development workflows, in its efficiency in small and large projects, and in its compatibility with many existing systems and protocols.
Git has been designed to support branching and tagging as first-class citizens (unlike SVN) and operations that affect branches and tags (such as merging or rollback) are also stored as part of the change history. Not all version control systems have this level of tracking.
Version control with
Git
Git is the best choice for most software teams today. While every team is different and should do their own analysis, here are the main reasons why version control with Git is preferred over alternatives:
Git
is good Git
has the functionality, performance, security, and flexibility that most teams and individual developers need. These Git attributes are detailed above. In side-by-side comparisons to most other alternatives, many teams find Git to be very favorable.
Git is a de facto standard Git is
the most widely adopted tool of its kind. This makes Git attractive for the following reasons. At Atlassian, almost all of our project’s source code is managed in Git.
A large number of developers already have experience with Git and a significant proportion of college graduates may have experience with Git alone. While some organizations may need to climb the learning curve when migrating to Git from another version control system, many of their current and future developers do not need to be Git trained.
In addition to the
benefits of a large talent pool, Git’s dominance also means that many third-party software tools and services are already integrated with Git, including IDEs, and our own tools like the DVCS Sourcetree desktop client, issue and project tracking software, Jira, and code hosting service, Bitbucket.
If you’re an inexperienced developer who wants to develop valuable skills in software development tools, when it comes to version control, Git should be on your list.
Git is a quality open source project
Git is
a
very well supported open source project with over a decade of solid management. The maintainers of the project have demonstrated a balanced judgment and a mature approach to meet the long-term needs of their users with regular releases that improve usability and functionality. The quality of open source software is easily examined and countless companies rely heavily on that quality.
Git enjoys great community support and a broad user base. The documentation is excellent and plentiful, including books, tutorials, and dedicated websites. There are also podcasts and video tutorials.
Being open source reduces the cost for amateur developers, as they can use Git without paying a fee. For use in open source projects, Git is undoubtedly the successor to previous generations of successful open source version control systems, SVN and CVS.
A
common criticism of Git is that it can be difficult to learn. Some of the terminology in Git will be novel to newcomers and to users of other systems, Git terminology may be different, for example, reverting in Git has a different meaning than in SVN or CVS. However, Git is very capable and provides a lot of power to its users. Learning to use that power can take some time, however, once it has been learned, that power can be used by the team to increase their development speed.
For those teams that come from an undistributed VCS, having a central repository may seem like a good thing they don’t want to lose. However, although Git has been designed as a distributed version control system (DVCS), with Git, you can still have an official, canonical repository where all changes to the software must be stored. With Git, because each developer’s repository is complete, their work doesn’t need to be limited by the availability and performance of the “core” server. During outages or offline, developers can still view the full project history. Because Git is flexible and distributed, you can work the way you’re used to, but get the added benefits of Git, some of which you don’t even realize you’re missing.
Now that you understand what version control is, what Git is, and why software teams should use it, read on to discover the benefits Git can provide across your organization.
