htdocs/git.xhtml

   1 <!--#include virtual="/doctype.inc" -->
   2   <head>
   3     <title>
   4       i-scream Git Repositories
   5     </title>
   6 <!--#include virtual="/style.inc" -->
   7   </head>
   8   <body>
   9     <div id="container">
  10       <div id="main">
  11 <!--#include virtual="/header.inc" -->
  12         <div id="contents">
  13           <h1 class="top">
  14             i-scream Git Repositories
  15           </h1>
  16           <p>
  17             The i-scream Git repositories contain the currently
  18             developed source code. All historic source code can be
  19             found in <a href="/cvs.xhtml">CVS</a>.
  20           </p>
  21           <p>
  22             All code available in the Git repositories is
  23             <a href= "/license.xhtml">licensed</a> under the GPL
  24             unless otherwise stated.
  25           </p>
  26           <h3>
  27             GitHub
  28           </h3>
  29           <p>
  30             Our Git repositories are located on GitHub. You can find
  31             then all under this GitHub Organisation.
  32           </p>
  33           <p>
  34             <a href="https://github.com/libstatgrab">https://github.com/libstatgrab</a>
  35           </p>
  36           <h3>
  37             Git guidelines
  38           </h3>
  39           <p>
  40             We've chosen a set of guidelines to work by so that
  41             everybody is clear about how the Git repositories will be
  42             used. This should make life easier for developers and
  43             users. The aim is to keep things clear and simple without
  44             adding unnecessary overheads. We don't have need for
  45             anything as complex as git-flow.
  46           </p>
  47           <ol>
  48             <li>
  49               The <code>master</code> branch will always be buildable
  50               and should be usable. Development work does not happen
  51               here directly.
  52             </li>
  53             <li>
  54               New releases will be taken from the <code>master</code>
  55               branch and will be tagged there.
  56             </li>
  57             <li>
  58               The master branch will never have its history rewritten.
  59             </li>
  60             <li>
  61               Development work will be done on branches. These
  62               branches may only live for the period of the development
  63               work. Once the work is complete and tested it will be
  64               merged to master and the branch may be deleted.
  65             </li>
  66             <li>
  67               The history on development branches may be rewritten to
  68               tidy things up before merging. This probably won't
  69               happen often, but don't get upset if it does.
  70             </li>
  71             <li>
  72               If you want to submit changes it's best to do them
  73               against the <code>master</code> branch unless you're
  74               specifically working with a developer on an issue
  75               already.
  76             </li>
  77             <li>
  78               Gratuitous merge commits should be avoided, particularly
  79               when merging development branches to <code>master</code>.
  80               They don't offer much in the way of useful information
  81               and make operations like bisect harder. In particular,
  82               if you pull changes to your local repository and end up
  83               with a merge commit you should use rebase to get rid of
  84               it before pushing.
  85             </li>
  86           </ol>
  87         </div>
  88 <!--#include virtual="/footer.inc" -->
  89       </div>
  90 <!--#include virtual="/menu.inc" -->
  91     </div>
  92   </body>
  93 </html>