Welcome to the Git development community.
This message is written by the maintainer and talks about how Git project is managed, and how you can work with it.
Note. The section on integration branches has been heavily rewritten in this edition; this is partly in preparation for a medium version bump.
The current maintainer is Junio C Hamano <gitster@pobox.com>. Spam filters learned that legitimate messages come to this address only from a very few sender addresses that are known to be good, and all other messages are likely to be spam unless they are also sent to the mailing list at the same time (i.e. "Reply-all" to the list message would reach the mailbox, but "Reply" will likely be thrown into the spam folder), so please do not send a message to this address unless it is also sent to the mailing list as well.
* Mailing list and the community
The development is primarily done on the Git mailing list. Help requests, feature proposals, bug reports and patches should be sent to the list address <git@vger.kernel.org>. You don't have to be subscribed to send messages. The convention on the list is to keep everybody involved on Cc:, so it is unnecessary to say "Please Cc: me, I am not subscribed".
As an anti-spam measure, the mailing list software may reject messages that are not text/plain and drops them on the floor. If you are a GMail user, you'd want to make sure "Plain text mode" is checked.
The mailing list, while welcoming non code contributions like bug reports, mostly discusses updating contents of the source tree to the (core) Git software, including documentation "git help" gives. Non-code contributions may have places other than the mailing list that are more preferrable. See the "other places" section near the end.
Before sending patches, please read Documentation/SubmittingPatches and Documentation/CodingGuidelines to familiarize yourself with the project convention.
If you sent a patch and you did not hear any response from anybody for several days, it does not necessarily mean that your patch was totally uninteresting; it may merely mean that it was lost in the noise. Please do not hesitate to send a reminder message in such a case. Messages getting lost in the noise may be a sign that those who can evaluate your patch don't have enough mental/time bandwidth to process them right at the moment, and it often helps to wait until the list traffic becomes calmer before sending such a reminder.
The list archive is available at a few public sites:
https://lore.kernel.org/git/
https://marc.info/?l=git
https://www.spinics.net/lists/git/For those who prefer to read it over NNTP:
nntp://nntp.lore.kernel.org/org.kernel.vger.git
nntp://news.public-inbox.org/inbox.comp.version-control.git
nntp://news.gmane.io/gmane.comp.version-control.gitare available.
When you point at a message in a mailing list archive, using its message ID is often the most robust (if not very friendly) way to do so, like this:
https://lore.kernel.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org
Often these web interfaces accept the message ID with enclosing <> stripped (like the above example to point at one of the most important message in the Git mailing list).
Some members of the development community can sometimes be found on the #git and #git-devel IRC channels on Libera Chat. Their logs are available at:
https://colabti.org/ircloggy/git/last
https://colabti.org/ircloggy/git-devel/lastThere is a volunteer-run newsletter to serve our community ("Git Rev News" https://git.github.io/rev_news/).
Git is a member project of Software Freedom Conservancy, a non-profit organization (https://sfconservancy.org/). To reach a committee of liaisons to the conservancy, contact them at <git@sfconservancy.org>.
For our expectations on the behaviour of the community participants towards each other, see CODE_OF_CONDUCT.md at the top level of the source tree, or:
https://github.com/git/git/blob/master/CODE_OF_CONDUCT.md
* Reporting bugs
When you think git does not behave as you expect, please do not stop your bug report with just "git does not work". "I used git in this way, but it did not work" is not much better, neither is "I used git in this way, and X happend, which is broken". It often is that git is correct to cause X happen in such a case, and it is your expectation that is broken. People would not know what other result Y you expected to see instead of X, if you left it unsaid.
Please remember to always state
- what you wanted to achieve;
- what you did (the version of git and the command sequence to reproduce the behavior);
- what you saw happen (X above);
- what you expected to see (Y above); and
- how the last two are different.
See https://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further hints. Our `git bugreport` tool gives you a handy way you can use to make sure you do not forget these points when filing a bug report.
If you think you found a security-sensitive issue and want to disclose it to us without announcing it to wider public, please contact us at our security mailing list <git-security@googlegroups.com>. This is a closed list that is limited to people who need to know early about vulnerabilities, including:
- people triaging and fixing reported vulnerabilities - people operating major git hosting sites with many users - people packaging and distributing git to large numbers of people
where these issues are discussed without risk of the information leaking out before we're ready to make public announcements.
* Repositories and documentation.
My public git.git repositories are (mirrored) at:
https://git.kernel.org/pub/scm/git/git.git/ https://kernel.googlesource.com/pub/scm/git/git https://repo.or.cz/alt-git.git/ https://github.com/git/git/ https://gitlab.com/git-scm/git/
This one shows not just the main integration branches, but also individual topics broken out:
https://github.com/gitster/git/
A few web interfaces are found at:
https://git.kernel.org/pub/scm/git/git.git https://kernel.googlesource.com/pub/scm/git/git https://repo.or.cz/w/alt-git.git
Preformatted documentation from the tip of the "master" branch can be found in:
https://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
https://repo.or.cz/git-{htmldocs,manpages}.git/
https://github.com/gitster/git-{htmldocs,manpages}.git/The manual pages formatted in HTML for the tip of "master" can be viewed online at:
https://git.github.io/htmldocs/git.html
* How various branches are used.
There are four integration branches in the git.git repository that track the source tree of Git: 'master', 'maint', 'next', and 'seen'. Commits are almost never made directly to them. Instead, after review on the mailing list, each new feature or bugfix is applied to its own topic branch forked from 'master' or 'maint' (or an older base when fixing an earlier bug), and kept out of 'master' while it is tested. The quality of topic branches is judged primarily by list discussions.
The 'master' branch holds well-tested changes ready for production and aims to be more stable than any released version. Feature releases are cut from its tip and named with two-dotted decimal digits (e.g., Git 2.56, tagged 'v2.56.0', made on September 28, 2026).
Whenever a feature release is made, 'maint' is forked from 'master'. Obvious, safe bugfixes for the latest feature release (and occasional developer aids such as CI updates, but almost never new features) are merged into it to cut maintenance releases named by incrementing the third digit (e.g., '2.47.1' for the '2.47' series). Bugfix topics are usually merged into 'master' before 'maint' to avoid last-minute issues, though embargoed security fixes may appear in both at the same time. 'maint' is merged up into 'master', primarily to propagate release notes forward.
Topic branches in good shape are merged into 'next', where new and exciting things take place. 'next' generally contains the tip of 'master' and is expected to work without major breakage while topics in it are polished to perfection before graduating to 'master'. Being in 'next' is no guarantee of appearing in any release: flawed commits or whole topics may be reverted from 'next' (or even from 'master' if a regression is found late). Because a bug may manifest only in your unique workflow, please help by building and using 'next' for your daily work and reporting problems to the mailing list before they reach 'master'.
The 'seen' branch bundles the remaining topics that the maintainer has seen and found potentially interesting; please do not read anything more into a topic being in 'seen', as topics whose ideas do not pan out are discarded before reaching 'next', just as topics can wither on the list without support. Contributors can use 'seen' to anticipate conflicts with others' in-flight topics and coordinate early. Before sending patches to the list (or via GitGitGadget), it is a good idea to test your topic in isolation and with temporary merges to 'next' and 'seen'.
You can run 'git log --oneline --first-parent master..seen' to see what topics are currently in flight. Its output mentions a 'jch' branch, an early part of 'seen' that contains all of 'next' and a bit more, used by the maintainer for his daily work.
'master' and 'maint' are never rewound, and 'next' is rebuilt from the tip of 'master' only after a feature release (using the topics that did not make the cut, possibly ejecting some). Consequently, until a topic is merged into 'next', updates should replace its patches with an improved version; once in 'next', updates must come as incremental patches explaining what reviewers missed and how it was corrected.
* Other people's trees.
Documentation/SubmittingPatches outlines to whom your proposed changes should be sent. As described in contrib/README, I would delegate fixes and enhancements in contrib/ area to the primary contributors of them.
Although the following are included in git.git repository, they have their own authoritative repository and maintainers:
- git-gui/ comes from git-gui project, maintained by Johannes Sixt:
https://github.com/j6t/git-gui
- gitk-git/ comes from gitk project, maintained by Johannes Sixt:
https://github.com/j6t/gitk
- po/ comes from the localization coordinator, Jiang Xin:
https://github.com/git-l10n/git-po/
When sending proposed updates and fixes to these parts of the system, please base your patches on these trees, not git.git (the former two even have different directory structures).
* Other places.
As the Git ecosystem has grown larger over the years, there are documentation sites and third-party tools that have been created and maintained by friendly third-parties. Reporting issues with them to the main mailing list is still welcomed by the list participants, but most likely you will be asked to contact these third-parties directly.
- git-scm website (https://www.git-scm.com/) is maintained directly on its GitHub repository and its issues are managed there.
https://github.com/git/git-scm.com/issues https://github.com/git/git-scm.com/?tab=readme-ov-file#contributing
- Git for Windows (https://gitforwindows.org/) is a project that packages (core) Git software with some other goodies for the Windows platform. They manage their own issues list and their changes are managed directly on GitHub via pull requests, focused primarily on Windows specific issues and their additions (like Windows installer).
https://github.com/git-for-windows/git/wiki/How-to-participate https://github.com/git-for-windows/git/issues
- The online edition of ProGit Book hosted at git-scm.com/book/ is managed by the Pro Git book folks, and they maintain their work and issues at their GitHub repository.
https://github.com/progit/progit2/issues https://github.com/progit/progit2/blob/main/CONTRIBUTING.md