1 Subject: A note from the maintainer
3 Welcome to the Git development community.
5 This message is written by the maintainer and talks about how Git
6 project is managed, and how you can work with it.
8 * Mailing list and the community
10 The development is primarily done on the Git mailing list. Help
11 requests, feature proposals, bug reports and patches should be sent to
12 the list address <git@vger.kernel.org>. You don't have to be
13 subscribed to send messages. The convention on the list is to keep
14 everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
17 Before sending patches, please read Documentation/SubmittingPatches
18 and Documentation/CodingGuidelines to familiarize yourself with the
21 If you sent a patch and you did not hear any response from anybody for
22 several days, it could be that your patch was totally uninteresting,
23 but it also is possible that it was simply lost in the noise. Please
24 do not hesitate to send a reminder message in such a case. Messages
25 getting lost in the noise is a sign that people involved don't have
26 enough mental/time bandwidth to process them right at the moment, and
27 it often helps to wait until the list traffic becomes calmer before
28 sending such a reminder.
30 The list archive is available at a few public sites:
32 http://news.gmane.org/gmane.comp.version-control.git/
33 http://marc.theaimsgroup.com/?l=git
34 http://www.spinics.net/lists/git/
36 For those who prefer to read it over NNTP (including the maintainer):
38 nntp://news.gmane.org/gmane.comp.version-control.git
40 When you point at a message in a mailing list archive, using
41 gmane is often the easiest to follow by readers, like this:
43 http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217
45 as it also allows people who subscribe to the mailing list as gmane
46 newsgroup to "jump to" the article.
48 Some members of the development community can sometimes also be found
49 on the #git IRC channel on Freenode. Its log is available at:
51 http://colabti.org/irclogger/irclogger_log/git
55 When you think git does not behave as you expect, please do not stop
56 your bug report with just "git does not work". "I used git in this
57 way, but it did not work" is not much better, neither is "I used git
58 in this way, and X happend, which is broken". It often is that git is
59 correct to cause X happen in such a case, and it is your expectation
60 that is broken. People would not know what other result Y you expected
61 to see instead of X, if you left it unsaid.
63 Please remember to always state
65 - what you wanted to achieve;
67 - what you did (the version of git and the command sequence to reproduce
70 - what you saw happen (X above);
72 - what you expected to see (Y above); and
74 - how the last two are different.
76 See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
79 * Repositories, branches and documentation.
81 My public git.git repositories are at:
83 git://git.kernel.org/pub/scm/git/git.git/
84 https://kernel.googlesource.com/pub/scm/git/git
85 git://repo.or.cz/alt-git.git/
86 https://github.com/git/git/
87 https://code.google.com/p/git-core/
88 git://git.sourceforge.jp/gitroot/git-core/git.git/
89 git://git-core.git.sourceforge.net/gitroot/git-core/git-core/
91 A few web interfaces are found at:
93 http://git.kernel.org/?p=git/git.git
94 https://kernel.googlesource.com/pub/scm/git/git
95 http://repo.or.cz/w/alt-git.git
97 Preformatted documentation from the tip of the "master" branch can be
100 git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
101 git://repo.or.cz/git-{htmldocs,manpages}.git/
102 https://code.google.com/p/git-{htmldocs,manpages}.git/
103 https://github.com/gitster/git-{htmldocs,manpages}.git/
105 You can browse the HTML manual pages at:
107 http://git-htmldocs.googlecode.com/git/git.html
109 There are four branches in git.git repository that track the source tree
110 of git: "master", "maint", "next", and "pu".
112 The "master" branch is meant to contain what are very well tested and
113 ready to be used in a production setting. Every now and then, a
114 "feature release" is cut from the tip of this branch and they
115 typically are named with three dotted decimal digits. The last such
116 release was 1.8.2 done on Mar 13, 2013. You can expect that the tip of
117 the "master" branch is always more stable than any of the released
120 Whenever a feature release is made, "maint" branch is forked off from
121 "master" at that point. Obvious, safe and urgent fixes after a feature
122 release are applied to this branch and maintenance releases are cut from
123 it. The maintenance releases are named with four dotted decimal, named
124 after the feature release they are updates to; the last such release was
125 1.8.1.5. New features never go to this branch. This branch is also
126 merged into "master" to propagate the fixes forward as needed.
128 A new development does not usually happen on "master". When you send a
129 series of patches, after review on the mailing list, a separate topic
130 branch is forked from the tip of "master" and your patches are queued
131 there, and kept out of "master" while people test it out. The quality of
132 topic branches are judged primarily by the mailing list discussions.
134 Topic branches that are in good shape are merged to the "next" branch. In
135 general, the "next" branch always contains the tip of "master". It might
136 not be quite rock-solid, but is expected to work more or less without major
137 breakage. The "next" branch is where new and exciting things take place. A
138 topic that is in "next" is expected to be polished to perfection before it
139 is merged to "master".
141 The "pu" (proposed updates) branch bundles all the remaining topic branches.
142 The topics on the branch are not complete, well tested, nor well documented
143 and need further work. When a topic that was in "pu" proves to be in a
144 testable shape, it is merged to "next".
146 You can run "git log --first-parent master..pu" to see what topics are
147 currently in flight. Sometimes, an idea that looked promising turns out
148 to be not so good and the topic can be dropped from "pu" in such a case.
150 The two branches "master" and "maint" are never rewound, and "next"
151 usually will not be either. After a feature release is made from
152 "master", however, "next" will be rebuilt from the tip of "master"
153 using the topics that didn't make the cut in the feature release.
155 Note that being in "next" is not a guarantee to appear in the next
156 release, nor even in any future release. There were cases that topics
157 needed reverting a few commits in them before graduating to "master",
158 or a topic that already was in "next" was reverted from "next" because
159 fatal flaws were found in it after it was merged.
162 * Other people's trees, trusted lieutenants and credits.
164 Documentation/SubmittingPatches outlines to whom your proposed changes
165 should be sent. As described in contrib/README, I would delegate fixes
166 and enhancements in contrib/ area to the primary contributors of them.
168 Although the following are included in git.git repository, they have their
169 own authoritative repository and maintainers:
171 - git-gui/ comes from git-gui project, maintained by Pat Thoyts:
173 git://repo.or.cz/git-gui.git
175 - gitk-git/ comes from Paul Mackerras's gitk project:
177 git://ozlabs.org/~paulus/gitk
179 - po/ comes from the localization coordinator, Jiang Xin:
181 https://github.com/git-l10n/git-po/
183 I would like to thank everybody who helped to raise git into the current
184 shape. Especially I would like to thank the git list regulars whose help
185 I have relied on and expect to continue relying on heavily:
187 - Linus Torvalds, Shawn Pearce, Johannes Schindelin, Nicolas Pitre,
188 René Scharfe, Jeff King, Jonathan Nieder, Johan Herland, Johannes
189 Sixt, Sverre Rabbelier, Michael J Gruber, Nguyễn Thái Ngọc Duy,
190 Ævar Arnfjörð Bjarmason and Thomas Rast for helping with general
191 design and implementation issues and reviews on the mailing list.
193 - Shawn and Nicolas Pitre for helping with packfile design and
194 implementation issues.
196 - Martin Langhoff, Frank Lichtenheld and Ævar Arnfjörð Bjarmason for
197 cvsserver and cvsimport.
199 - Paul Mackerras for gitk.
201 - Eric Wong, David D. Kilzer and Sam Vilain for git-svn.
203 - Simon Hausmann, Pete Wyckoff and Luke Diamond for git-p4.
205 - Jakub Narebski, John Hawley, Petr Baudis, Luben Tuikov, Giuseppe
206 Bilotta for maintaining and enhancing gitweb.
208 - Ævar Arnfjörð Bjarmason for kicking off the i18n effort, and Jiang
209 Xin for volunteering to be the l10n coordinator.
211 - Jens Lehmann, Heiko Voigt and Lars Hjemli for submodule related
214 - J. Bruce Fields, Jonathan Nieder, Michael J Gruber and Thomas Rast for
215 documentation (and countless others for proofreading and fixing).
217 - Alexandre Julliard for Emacs integration.
219 - David Aguilar and Charles Bailey for taking good care of git-mergetool
220 (and Theodore Ts'o for creating it in the first place) and git-difftool.
222 - Johannes Schindelin, Johannes Sixt, Erik Faye-Lund, Pat Thoyts and others
223 for their effort to move things forward on the Windows front.
225 - People on non-Linux platforms for keeping their eyes on portability;
226 especially, Randal Schwartz, Theodore Ts'o, Jason Riedy, Thomas Glanzmann,
227 Brandon Casey, Jeff King, Alex Riesen and countless others.