Small and Fast

Git is fast. With Git, nearly all operations are performed locally, giving it a huge speed advantage on centralized systems that constantly have to communicate with a server somewhere.

Git was built to work on the Linux kernel, meaning that it has had to effectively handle large repositories from day one. Git is written in C, reducing the overhead of runtimes associated with higher-level languages. Speed and performance has been a primary design goal of Git from the start.

Benchmarks

Let's see how common operations stack up against Subversion, a common centralized version control system that is similar to CVS or Perforce. Smaller is faster.

For testing, large AWS instances were set up in the same availability zone. Git and SVN were installed on both machines, the Ruby repository was copied to both Git and SVN servers, and common operations were performed on both.

In some cases, the commands don't match up exactly. Here, matching on the lowest common denominator was attempted. For example, the 'commit' tests also include the time to push for Git, though most of the time you would not actually be pushing to the server immediately after a commit where the two commands cannot be separated in SVN.

All of these times are in seconds.

Note that this is the best case scenario for SVN—a server with no load with a gigabit connection to the client machine. Nearly all of these times would be even worse for SVN if that connection was slower, while many of the Git times would not be affected.

Clearly, in many of these common version control operations, Git is one or two orders of magnitude faster than SVN, even under ideal conditions for SVN.

One place where Git is slower is in the initial clone operation. Here, Git is downloading the entire history rather than only the latest version. As seen in the above charts, it's not considerably slower for an operation that is only performed once.

It's also interesting to note that the size of the data on the client side is very similar even though Git also has every version of every file for the entire history of the project. This illustrates how efficient it is at compressing and storing data on the client side.

Distributed

One of the nicest features of any Distributed SCM, Git included, is that it's distributed. This means that instead of doing a "checkout" of the current tip of the source code, you do a "clone" of the entire repository.

Multiple Backups

This means that even if you're using a centralized workflow, every user essentially has a full backup of the main server. Each of these copies could be pushed up to replace the main server in the event of a crash or corruption. In effect, there is no single point of failure with Git unless there is only a single copy of the repository.

Any Workflow

Because of Git's distributed nature and superb branching system, an almost endless number of workflows can be implemented with relative ease.

Subversion-Style Workflow

A centralized workflow is very common, especially from people transitioning from a centralized system. Git will not allow you to push if someone has pushed since the last time you fetched, so a centralized model where all developers push to the same server works just fine.

Integration Manager Workflow

Another common Git workflow involves an integration manager — a single person who commits to the 'blessed' repository. A number of developers then clone from that repository, push to their own independent repositories, and ask the integrator to pull in their changes. This is the type of development model often seen with open source or GitHub repositories.

Dictator and Lieutenants Workflow

For more massive projects, a development workflow like that of the Linux kernel is often effective. In this model, some people ('lieutenants') are in charge of a specific subsystem of the project and they merge in all changes related to that subsystem. Another integrator (the 'dictator') can pull changes from only his/her lieutenants and then push to the 'blessed' repository that everyone then clones from again.

Free and Open Source

Git is released under the GNU General Public License version 2.0, which is an open source license. The Git project chose to use GPLv2 to guarantee your freedom to share and change free software---to make sure the software is free for all its users.

However, we do restrict the use of the term "Git" and the logos to avoid confusion. Please see our trademark policy for details.

GIT TRADEMARK POLICY

1 Purpose

The Git Project is a member project of Software Freedom Conservancy ("Conservancy"). Conservancy holds rights in the Marks on behalf of the Git Project in accordance with its non- profit charitable mission.

Conservancy has adopted this Policy to protect the Marks (as defined below) and to make sure that the identity of Git software and its free and open source nature is clear to everyone. By using this Policy, the Git Project can spread the use of the Git software while making sure that the Marks are protected in a way that's consistent with U.S. trademark law (U.S. Registration 4680534). This Policy is written to allow all clear and appropriate use of the Marks while disapproving use of the Marks in ways that could confuse users as to where the software came from, or that implies an otherwise non- existent association with the Git Project. By adhering to this Policy, you help to promote to the public the freedom to use and develop the Git software.

Throughout this Policy, the word "Marks" refers to the following:

• the literal mark "Git"

• The logos and graphic marks displayed and available for download at https://git-scm.com/downloads/logos

• The slogan "the stupid content tracker"

This Policy is only concerned with the Marks associated with the Git Project, and does not address any copyrights associated with the Git software.

2 Guidelines for using the Marks

2.1 Trademark symbol on first mention

The first prominent mention of a Mark should be immediately followed by a symbol for, as applicable, a registered trademark (®) or an unregistered trademark (™). For example: "Git™".

This requirement is waived in all contexts where such marks are not required to protect the intellectual property rights associated with the Marks, such as email, online discussion, and academic papers. We encourage the use of the applicable symbols whenever possible, but recognize that many users will omit them in non-commercial and informal contexts.

You can use "Git and the Git logo are either registered trademarks or trademarks of Software Freedom Conservancy, Inc., corporate home of the Git Project, in the United States and/or other countries." when you need to mention "Git" in e.g. list of trademarks held by other people.

2.2 Use of the Marks without written permission

You may use the Marks without prior written permission (subject to the other sections):

1. To refer to the Git software in substantially unmodified form. "Substantially unmodified" means built from the source code provided by the Git Project, possibly with minor modifications including but not limited to: the enabling or disabling of certain features by default, translations into other languages, changes required for compatibility with a particular operating system distribution, or the inclusion of bug-fix patches.

2. To identify the Git software as a distinct component of a software offering.

3. To factually refer to the Git Project itself, its products, or its protocols.

In addition, you may use the Marks to refer to products, services, or communities outside of the Git software and Git Project without written permission in the following contexts:

4. When referring to Git software that is not substantially unmodified, to say that such software is a "derivative of" or "based on" Git.
5. When referring to a third-party software product and/or service that is interoperable with the Git software, in the format "[Product Name] for Git" -- provided that such use otherwise complies with the rest of this Policy.

We do not charge a fee for a license to use the Marks in these contexts. However, we do of course welcome donations. If you're interested in donating to the Git Project, care of Conservancy, visit https://git-scm.com/sfc. Conservancy is a United States 501(c)(3) public charity.

2.3 Prohibited usages of the Marks

You may not use the Marks in the following ways:

• In any way likely to cause confusion as to the identity of the Git Project, the provenance of its software, or the software's license.

• In any way that indicates a greater degree of association between you and the Git Project than actually exists.

• In any way that implies a designated successor to Git (e.g., "Git++" is not permitted).

• In any way that indicates that Git favors one distribution, platform, product, etc. over another except where explicitly indicated in writing by Conservancy.

• In any other way that dilutes or otherwise infringes upon the trademark rights of Conservancy and the Git Project in the Marks.

• To refer to the Git software, modified by a third party to the point of inoperability with Git software in substantially unmodified form.

In addition, you may not use any of the Marks as a syllable in a new word or as part of a portmanteau (e.g., "Gitalicious", "Gitpedia") used as a mark for a third-party product or service without Conservancy's written permission. For the avoidance of doubt, this provision applies even to third-party marks that use the Marks as a syllable or as part of a portmanteau to refer to a product or service's use of Git code.

2.4 Limitations to this Policy

This Policy does not confer any rights to use the trademarks "Software Freedom Conservancy," "Conservancy," or to use any other trademarks other than the Marks listed in Section 1. This Policy does not authorize you to act as an agent for Conservancy, enter into any agreement on behalf of or otherwise create any liability for the Git Project or Conservancy.

2.5 Use of the Marks in merchandising

You may not create and/or sell merchandise bearing any of the Marks without Conservancy's express written permission. If you are interested in using creating and/or selling merchandise bearing any of the the Marks, please send proofs of your designs to us at [email protected].

3 Rights reserved by Conservancy

Conservancy reserves the sole right to:

• Determine compliance with this Policy.

• Modify this Policy in ways consistent with its mission of protecting the public.

• Grant exceptions to this Policy, of any kind and for any reason whatsoever, other clauses notwithstanding.

4 Questions

This Policy is designed to keep the Marks safe in order to protect this software's reputation, earned by the contributions of the Git Project to the free and open source software community and to the public at large. If you see any use of the Marks anywhere that you think violates this Policy or otherwise goes against the spirit of the Git Project and Conservancy's mission, please bring it to Conservancy's attention by contacting us at [email protected].

If you have questions about using the Marks, or if you think you should be able to use the Marks for any purpose not allowed by this Policy and would like permission for that use, please contact Conservancy by emailing [email protected] or by writing to Git Project c/o Software Freedom Conservancy, 137 Montague St. Ste 380, Brooklyn, NY 11201-3548.

Documentation

Reference

Reference Manual

The official and comprehensive man pages that are included in the Git package itself.

Quick reference guides: GitHub Cheat Sheet | Visual Git Cheat Sheet

Book

Pro Git

The entire Pro Git book written by Scott Chacon and Ben Straub is available to read online for free. Dead tree versions are available on Amazon.com.

Community

Mailing List

General questions or comments for the Git community can be sent to the mailing list by using the email address [email protected].

If you wish to report any possible bug for Git, please use this mailing list as well.

You do not need to subscribe: you will be Cc'd in replies. Please keep the Cc list intact when replying (use "Reply to all"). Greylisting may delay your first post for a few hours. Note also that the list only accepts plain-text email; please disable HTML in your outgoing messages.

By subscribing (click here), you can make sure you're not missing follow-up discussions and you can also learn about other development in the community. The list archive can be found on public-inbox.

Windows-specific questions can also be sent to the Git for Windows mailing list (if in doubt whether your question is Windows-specific, just use the general Git mailing list). Please submit Windows-specific bugs to Git for Windows' bug tracker.

There is also Git user mailing list on Google Groups which is a nice place for beginners to ask about anything. If you're a downstream packager of Git, consider joining the Git packagers mailing list for low-volume announcements from the developers, as well as other discussion related to packaging & porting Git.

Bug Reporting

Bugs in git can be reported directly to the mailing list (see above for details). Note that you do not need to subscribe to the list to send to it. You can help us out by attempting to reproduce the bug in the latest released version of git, or if you're willing to build git from source, the next branch. Sometimes an attempted fix may be pending in this branch, in which case your feedback as to whether the fix worked for you will be appreciated.

If you are using git 2.27.0 or later, you can run git bugreport in the repository where you observed the bug, which generates a template to guide you through writing a useful bug report and gathers some diagnostic information about your environment.

Bugs related to this website can be reported at its issue tracker. Bugs related to the content of the "Pro Git" book can be reported at its issue tracker.

If you are new to submitting bugs, you might find this guide helpful for producing useful bug reports.

Reporting Security Issues

Issues which are security relevant should be disclosed privately to the Git Security mailing list.

IRC Channel

If the manpages and this book aren’t enough and you need in-person help, you can try the #git channel on the Libera Chat IRC server (irc.libera.chat). These channels are regularly filled with hundreds of people who are all very knowledgeable about Git and are often willing to help. The #git-devel channel welcomes Git development discussion, and might be able to help you contribute to Git.

If you need specific help about one of the for-profit Git hosting sites, you might try their own IRC channels (such as #github or #gitlab) on the same IRC server.

Newsletter

There is a monthly community newsletter called "Git Rev News", with its archive and its latest edition. Information on how to subscribe can be found on the dedicated webpage.

Contributing to Git

The Documentation directory in the Git source code has several files of interest to developers who are looking to help contribute. After reading the coding guidelines, you can learn how to submit patches. If you are just starting out, you can read the My First Contribution tutorial. For those looking to get more deeply involved, there is a howto for Git maintainers.

The Git Developer Pages have a Hacking Git page which lists useful development resources. They also have information for people applying to work on Git as part of programs like Outreachy or the Google Summer of Code.