To: git@vger.kernel.orgSubject: A note from the maintainerWelcome to the Git development community.This message is written by the maintainer and talks about how Gitproject is managed, and how you can work with it.The current maintainer is Junio C Hamano <gitster@pobox.com>. Spamfilters learned that legitimate messages come to this address onlyfrom a very few sender addresses that are known to be good, and allother messages are likely to be spam unless they are also sent to themailing list at the same time (i.e. "Reply-all" to the list messagewould reach the mailbox, but "Reply" will likely be thrown into thespam folder), so please do not send a message to this address unlessit is also sent to the mailing list as well.* Mailing list and the communityThe development is primarily done on the Git mailing list. Helprequests, feature proposals, bug reports and patches should be sent tothe list address <git@vger.kernel.org>. You don't have to besubscribed to send messages. The convention on the list is to keepeverybody 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 rejects messagesthat are not text/plain and drops them on the floor. If you are aGMail user, you'd want to make sure "Plain text mode" is checked.The mailing list, while welcoming non code contributions like bugreports, 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 listthat are more preferrable. See the "other places" section near theend.Before sending patches, please read Documentation/SubmittingPatchesand Documentation/CodingGuidelines to familiarize yourself with theproject convention.If you sent a patch and you did not hear any response from anybody forseveral days, it does not necessarily mean that your patch was totallyuninteresting; 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 canevaluate your patch don't have enough mental/time bandwidth to processthem right at the moment, and it often helps to wait until the listtraffic 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.gitare available.When you point at a message in a mailing list archive, using itsmessage ID is often the most robust (if not very friendly) way to doso, like this: https://lore.kernel.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.orgOften these web interfaces accept the message ID with enclosing <>stripped (like the above example to point at one of the most importantmessage in the Git mailing list).Some members of the development community can sometimes be found onthe #git and #git-devel IRC channels on Libera Chat. Their logs areavailable at: https://colabti.org/ircloggy/git/last https://colabti.org/ircloggy/git-devel/lastThere is a volunteer-run newsletter to serve our community ("Git RevNews" https://git.github.io/rev_news/).Git is a member project of software freedom conservancy, a non-profitorganization (https://sfconservancy.org/). To reach a committee ofliaisons to the conservancy, contact them at <git@sfconservancy.org>.For our expectations on the behaviour of the community participantstowards each other, see CODE_OF_CONDUCT.md at the top level of the sourcetree, or: https://github.com/git/git/blob/master/CODE_OF_CONDUCT.md* Reporting bugsWhen you think git does not behave as you expect, please do not stopyour bug report with just "git does not work". "I used git in thisway, but it did not work" is not much better, neither is "I used gitin this way, and X happend, which is broken". It often is that git iscorrect to cause X happen in such a case, and it is your expectationthat is broken. People would not know what other result Y youexpected 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 furtherhints. Our `git bugreport` tool gives you a handy way you can use tomake sure you do not forget these points when filing a bug report.If you think you found a security-sensitive issue and want to discloseit to us without announcing it to wider public, please contact us atour security mailing list <git-security@googlegroups.com>. This isa closed list that is limited to people who need to know early aboutvulnerabilities, 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 peoplewhere these issues are discussed without risk of the informationleaking 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 alsoindividual 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.gitPreformatted documentation from the tip of the "master" branch can befound 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 beviewed online at: https://git.github.io/htmldocs/git.html* How various branches are used.There are four "integration" branches in git.git repository that trackthe source tree of git: "master", "maint", "next", and "seen". Theyhowever almost never get new commits made directly on them. Instead,a branch is forked from either "master" or "maint" for each "topic",whether it is a new feature or a fix for a bug, and holds a set ofcommits that belong to the same theme. Such a "topic branch" is thenmerged to these integration branches.The "master" branch is meant to contain what are very well tested andready to be used in a production setting. Every now and then, a"feature release" is cut from the tip of this branch. They used to benamed with three dotted decimal digits (e.g., "1.8.5"), but we haveswitched the versioning scheme and "feature releases" are named withttwo-dotted decimal digits (e.g. "2.53"), whose tag ends with ".0"(e.g., "v2.53.0").The last such release was Git 2.53, made on Feb 2nd, 2026. We aim tomake sure that the tip of the "master" branch is always more stablethan any of the released versions.Whenever a feature release is made, "maint" branch is forked off from"master" at that point. Obvious and safe fixes for bugs in the latestfeature release are merged to this branch and maintenance releases arecut from it. Usually the topic branches that contain these fixes aremerged to the "master" branch first, before getting merged to the"maint" branch, to reduce the chance of last-minute issues, butthings like embargoed security fixes may first appear in the "maint"and merged up to "master" at the same time. The maintenance releasesused to be named with four dotted decimal, named after the featurerelease they are updates to (e.g., "1.8.5.1" was the first maintenancerelease for "1.8.5" feature release). These days, maintenance releasesare named by incrementing the last digit of three-dotted decimal name(e.g., "2.47.1" was the second maintenance release for the "2.47" series).New features almost never go to the "maint" branch, although changesto help Git developers themselves, including CI updates, are oftenmerged down even if they are not bugfixes at all. The "maint" branchis merged up into the "master" branch, primarily to propagate thedescription in the release notes forward.When you send a series of patches, after review discussions on themailing list, a separate topic branch is forked from the tip of"master" (or somewhere older, especially when the topic is aboutfixing an earlier bug) and your patches are applied on that topicbranch, and kept out of "master" while people test it out. Thequality of topic branches are judged primarily by the mailing listdiscussions.Topic branches that are in good shape are merged to the "next" branch.The "next" branch is where new and exciting things take place. Ingeneral, the "next" branch always contains the tip of "master". Itmight not be quite rock-solid, but is expected to work more or lesswithout major breakage. A topic that is in "next" is expected to bepolished to perfection before it is merged to "master". Please helpthis process by building & using the "next" branch for your dailywork, and reporting any new bugs you find to the mailing list, beforethe breakage is merged down to the "master". This process depends onyour participation, as the way you use Git may be unique from others,and a new bug may only manifest itself when used in the way you useGit, not noticed by others.The "seen" branch bundles the remaining topic branches that themaintainer happens to have seen to remind the maintainer that thetopics in them might become interesting when they are polished. Atopic in "seen" can and does get discarded before it gets merged to"next" if its idea does not pan out, just like a topic can wither onthe list without anybody supporting it. Please do not read anythingmore than "the maintainer has seen it and found it potentiallyinteresting" into a topic being in "seen".The contributors can use the "seen" branch to anticipate what topicsby others may cause conflicts with their own work, and find people whoare working on these topics to talk to before the potential conflictsget out of control. It would be a good idea to fork your work frommaint or master and to (1) test it by itself, (2) test a temporarymerge of it to "next" and (3) test a temporary merge to it to "seen",before sending it to the list (or asking GitGitGadget to send it tothe list).You can run "git log --oneline --first-parent master..seen" to seewhat topics are currently in flight. The output of the above commandtalks about a "jch" branch, which is an early part of the "seen" branch;that branch contains all topics that are in "next" and a bit more (butnot all of "seen") and is used by the maintainer for his daily work.The two branches "master" and "maint" are never rewound, and "next"usually will not be either. After a feature release is made from"master", however, "next" will be rebuilt from the tip of "master"using the topics that didn't make the cut in the feature release.Some topics that used to be in "next" during the previous cycle mayget ejected from "next" when this happens.A natural consequence of how "next" and "seen" bundles topics togetheris that until a topic is merged to "next", updates to it is expectedby replacing the patch(es) in the topic with an improved version, andonce a topic is merged to "next", updates to it needs to come asincremental patches, pointing out what was wrong in the previouspatches and how the problem was corrected. The idea is that if manyreviewers thought it has seen enough eyeballs and is good enough for"next", yet we later find that there was something we all missed, thatis worth a separate explanation, e.g., "The primary motivation behindthe series is still good, but for such and such reasons we missed thiscase we are fixing.", hence we prefer follow-up incremental patches.Note that being in "next" is not a guarantee to appear in the nextrelease, nor even in any future release. There were cases that topicsneeded reverting a few commits in them before graduating to "master",or a topic that already was in "next" was reverted from "next" becausefatal flaws were found in it after it was merged to "next". The samecan be said to "master"---there were cases that we needed to revert atopic from it because a regression was found after it was merged to"master", instead of while it was still in "next". To prevent it fromhappening, those who care about the quality of the next release, thosewho want to ensure that the next release will not break theirworkflow, are strongly encouraged to build and try out "next" in theirdaily work and report problems.* Other people's trees.Documentation/SubmittingPatches outlines to whom your proposed changesshould be sent. As described in contrib/README, I would delegate fixesand enhancements in contrib/ area to the primary contributors of them.Although the following are included in git.git repository, they have theirown 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 twoeven have different directory structures).* Other places.As the Git ecosystem has grown larger over the years, there aredocumentation sites and third-party tools that have been created andmaintained by friendly third-parties. Reporting issues with them tothe main mailing list is still welcomed by the list participants, butmost 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