X-Git-Url: http://git.i-scream.org/?a=blobdiff_plain;f=www%2Fgit.xhtml;h=448db0fce879b3eec4c0ea794f44061984ee0701;hb=3cd5172f748345033f24f402cf4899394faa70cb;hp=c4fb7e425774e96d70b2b76652b685a638e1110e;hpb=c8e0a4a33a54a770ba9a71524438cd321cd64937;p=www.i-scream.org.git

diff --git a/www/git.xhtml b/www/git.xhtml
index c4fb7e4..448db0f 100644
--- a/www/git.xhtml
+++ b/www/git.xhtml
@@ -20,7 +20,8 @@
           </p>
           <p>
             All code available in the Git repositories is
-            <a href= "/license.xhtml">licensed</a> under the GPL.
+            <a href= "/license.xhtml">licensed</a> under the GPL
+            unless otherwise stated.
           </p>
           <h3>
             Web Access
@@ -74,6 +75,57 @@ git clone ssh://git@git.i-scream.org/libstatgrab
           <p>
             <a href="http://github.com/i-scream">http://github.com/i-scream</a>
           </p>
+          <h3>
+            Git guidelines
+          </h3>
+          <p>
+            We've chosen a set of guidelines to work by so that
+            everybody is clear about how the Git repositories will be
+            used. This should make life easier for developers and
+            users. The aim is to keep things clear and simple without
+            adding unnecessary overheads. We don't have need for
+            anything as complex as git-flow.
+          </p>
+          <ol>
+            <li>
+              The <code>master</code> branch will always be buildable
+              and should be usable. Development work does not happen
+              here directly.
+            </li>
+            <li>
+              New releases will be taken from the <code>master</code>
+              branch and will be tagged there.
+            </li>
+            <li>
+              The master branch will never have its history rewritten.
+            </li>
+            <li>
+              Development work will be done on branches. These
+              branches may only live for the period of the development
+              work. Once the work is complete and tested it will be
+              merged to master and the branch may be deleted.
+            </li>
+            <li>
+              The history on development branches may be rewritten to
+              tidy things up before merging. This probably won't
+              happen often, but don't get upset if it does.
+            </li>
+            <li>
+              If you want to submit changes it's best to do them
+              against the <code>master</code> branch unless you're
+              specifically working with a developer on an issue
+              already.
+            </li>
+            <li>
+              Gratuitous merge commits should be avoided, particularly
+              when merging development branches to <code>master</code>.
+              They don't offer much in the way of useful information
+              and make operations like bisect harder. In particular,
+              if you pull changes to your local repository and end up
+              with a merge commit you should use rebase to get rid of
+              it before pushing.
+            </li>
+          </ol>
         </div>
 <!--#include virtual="/footer.inc" -->
       </div>