+++ /dev/null
-<!--#include virtual="/doctype.inc" -->
- <head>
- <title>
- i-scream Git Repositories
- </title>
-<!--#include virtual="/style.inc" -->
- </head>
- <body>
- <div id="container">
- <div id="main">
-<!--#include virtual="/header.inc" -->
- <div id="contents">
- <h1 class="top">
- i-scream Git Repositories
- </h1>
- <p>
- The i-scream Git repositories contain the currently
- developed source code. All historic source code can be
- found in <a href="/cvs.xhtml">CVS</a>.
- </p>
- <p>
- All code available in the Git repositories is
- <a href= "/license.xhtml">licensed</a> under the GPL
- unless otherwise stated.
- </p>
- <h3>
- Web Access
- </h3>
- <p>
- We use GitWeb to provide a visual frontend to the Git
- repositories. It allows you to browse around each repository,
- viewing any version of a file, and the differences between
- different versions. There is also a link to download the
- latest version of any section.
- </p>
- <p>
- <a href="http://git.i-scream.org/">http://git.i-scream.org/</a>
- </p>
- <h3>
- Anonymous Git Access (read-only)
- </h3>
- <p>
- Anyone can access the i-scream Git repositories in anonymous
- read-only mode. The following commands will both allow you
- to check out the libstatgrab repository. To see what other
- repositories are available you can look at the web frontend.
- Choose whichever protocol you prefer.
- </p>
- <pre>
-git clone http://git.i-scream.org/libstatgrab
-git clone git://git.i-scream.org/libstatgrab
-</pre>
- <h3>
- Developer CVS Access (write)
- </h3>
- <p>
- The i-scream development team have write access to the
- required Git repositories. This is only available over SSH on
- a non-standard port. You will need to have a SSH key
- installed on the server first. Then just clone and push
- using ssh.
- </p>
- <pre>
-git clone ssh://git@git.i-scream.org/libstatgrab
-</pre>
- <h3>
- GitHub Mirror
- </h3>
- <p>
- Our Git repositories are mirrored on GitHub. The master
- repository that we'll push commits to is located here, but
- we provide the GitHub mirrors to make it easier for you to
- make changes and work with our code.
- </p>
- <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>
-<!--#include virtual="/menu.inc" -->
- </div>
- </body>
-</html>
i-scream / www.i-scream.org.git / blobdiff