Welcome to 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.
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 addressBefore 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 could be that your patch was totally uninteresting, but it also is possible that it was simply lost in the noise. Please do not hesitate to send a reminder message in such a case. Messages getting lost in the noise is a sign that people involved 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:
http://news.gmane.org/gmane.comp.version-control.git/
http://marc.theaimsgroup.com/?l=git
http://www.spinics.net/lists/git/
For those who prefer to read it over NNTP (including the maintainer):http://marc.theaimsgroup.com/?l=git
http://www.spinics.net/lists/git/
nntp://news.gmane.org/gmane.comp.version-control.git
When you point at a message in a mailing list archive, using gmane is often the easiest to follow by readers, like this:as it also allows people who subscribe to the mailing list as gmane newsgroup to "jump to" the article.
Some members of the development community can sometimes also be found on the #git IRC channel on Freenode. Its log is available at:
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.
Repositories, branches and documentation.
My public git.git repositories are at:
git://git.kernel.org/pub/scm/git/git.git/
git://repo.or.cz/alt-git.git/
https://github.com/git/git/
https://code.google.com/p/git-core/
git://git.sourceforge.jp/gitroot/git-core/git.git/
git://git-core.git.sourceforge.net/gitroot/git-core/git-core/
A few gitweb interfaces are found at:git://repo.or.cz/alt-git.git/
https://github.com/git/git/
https://code.google.com/p/git-core/
git://git.sourceforge.jp/gitroot/git-core/git.git/
git://git-core.git.sourceforge.net/gitroot/git-core/git-core/
Preformatted documentation from the tip of the "master" branch can be found in:
git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
git://repo.or.cz/git-{htmldocs,manpages}.git/
https://code.google.com/p/git-{htmldocs,manpages}.git/
https://github.com/gitster/git-{htmldocs,manpages}.git/
You can browse the HTML manual pages at:git://repo.or.cz/git-{htmldocs,manpages}.git/
https://code.google.com/p/git-{htmldocs,manpages}.git/
https://github.com/gitster/git-{htmldocs,manpages}.git/
https://git-htmldocs.googlecode.com/git/git.html
There are four branches in git.git repository that track the source tree of git: "master", "maint", "next", and "pu".The "master" branch is meant to contain what are very well tested and ready to be used in a production setting. Every now and then, a "feature release" is cut from the tip of this branch and they typically are named with three dotted decimal digits. The last such release was 1.8.1 done on Dec 31, 2012. You can expect that the tip of the "master" branch is always more stable than any of the released versions.
Whenever a feature release is made, "maint" branch is forked off from "master" at that point. Obvious, safe and urgent fixes after a feature release are applied to this branch and maintenance releases are cut from it. The maintenance releases are named with four dotted decimal, named after the feature release they are updates to; the last such release was 1.8.1.3. New features never go to this branch. This branch is also merged into "master" to propagate the fixes forward as needed.
A new development does not usually happen on "master". When you send a series of patches, after review on the mailing list, a separate topic branch is forked from the tip of "master" and your patches are queued there, and kept out of "master" while people test it out. The quality of topic branches are judged primarily by the mailing list discussions.
Topic branches that are in good shape are merged to the "next" branch. In general, the "next" branch always contains the tip of "master". It might not be quite rock-solid, but is expected to work more or less without major breakage. The "next" branch is where new and exciting things take place. A topic that is in "next" is expected to be polished to perfection before it is merged to "master".
The "pu" (proposed updates) branch bundles all the remaining topic branches. The topics on the branch are not complete, well tested, nor well documented and need further work. When a topic that was in "pu" proves to be in testable shape, it is merged to "next".
You can run "git log --first-parent master..pu" to see what topics are currently in flight. Sometimes, an idea that looked promising turns out to be not so good and the topic can be dropped from "pu" in such a case.
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.
Note that being in "next" is not a guarantee to appear in the next release, nor even in any future release. There were cases that topics needed reverting a few commits in them before graduating to "master", or a topic that already was in "next" was reverted from "next" because fatal flaws were found in it after it was merged.
Other people's trees, trusted lieutenants and credits.
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 Pat Thoyts:
git://repo.or.cz/git-gui.git
- gitk-git/ comes from Paul Mackerras's gitk project:
git://git.kernel.org/pub/scm/gitk/gitk.git
- po/ comes from the localization coordinator, Jiang Xin:
git://github.com/git-l10n/git-po
I would like to thank everybody who helped to raise git into the current shape. Especially I would like to thank the git list regulars whose help I have relied on and expect to continue relying on heavily:- Linus Torvalds, Shawn Pearce, Johannes Schindelin, Nicolas Pitre, René Scharfe, Jeff King, Jonathan Nieder, Johan Herland, Johannes Sixt, Sverre Rabbelier, Michael J Gruber, Nguyễn Thái Ngọc Duy, Ævar Arnfjörð Bjarmason and Thomas Rast for helping with general design and implementation issues and reviews on the mailing list.
- Shawn and Nicolas Pitre for helping with packfile design and implementation issues.
- Martin Langhoff, Frank Lichtenheld and Ævar Arnfjörð Bjarmason for cvsserver and cvsimport.
- Paul Mackerras for gitk.
- Eric Wong, David D. Kilzer and Sam Vilain for git-svn.
- Simon Hausmann, Pete Wyckoff and Luke Diamond for git-p4.
- Jakub Narebski, John Hawley, Petr Baudis, Luben Tuikov, Giuseppe Bilotta for maintaining and enhancing gitweb.
- Ævar Arnfjörð Bjarmason for kicking off the i18n effort, and Jiang Xin for volunteering to be the l10n coordinator.
- J. Bruce Fields, Jonathan Nieder, Michael J Gruber and Thomas Rast for documentation (and countless others for proofreading and fixing).
- Alexandre Julliard for Emacs integration.
- David Aguilar and Charles Bailey for taking good care of git-mergetool (and Theodore Ts'o for creating it in the first place) and git-difftool.
- Johannes Schindelin, Johannes Sixt, Erik Faye-Lund, Pat Thoyts and others for their effort to move things forward on the Windows front.
- People on non-Linux platforms for keeping their eyes on portability; especially, Randal Schwartz, Theodore Ts'o, Jason Riedy, Thomas Glanzmann, Brandon Casey, Jeff King, Alex Riesen and countless others.
