ViewVC Help
View File | Revision Log | Show Annotations | Revision Graph | Root Listing
root/i-scream/web/www/git.xhtml
(Generate patch)

Comparing web/www/git.xhtml (file contents):
Revision 1.3 by tdb, Mon Jul 15 22:15:54 2013 UTC vs.
Revision 1.4 by tdb, Tue Jul 16 10:18:53 2013 UTC

# Line 75 | Line 75 | git clone ssh://git@git.i-scream.org/libstatgrab
75            <p>
76              <a href="http://github.com/i-scream">http://github.com/i-scream</a>
77            </p>
78 <          <h3>
79 <            Git guidelines
80 <          </h3>
81 <          <p>
82 <            We've chosen a set of guidelines to work by so that
83 <            everybody is clear about how the Git repositories will be
84 <            used. This should make life easier for developers and
85 <            users. The aim is to keep things clear and simple without
86 <            adding unnecessary overheads. We don't have need for
87 <            anything as complex as git-flow.
88 <          </p>
89 <          <ol>
90 <            <li>
91 <              The <code>master</code> branch will always be buildable
92 <              and should be usable. Development work does not happen
93 <              here directly.
94 <            </li>
95 <            <li>
96 <              New releases will be taken from the <code>master</code>
97 <              branch and will be tagged there.
98 <            </li>
99 <            <li>
100 <              The master branch will never have its history rewritten.
101 <            </li>
102 <            <li>
103 <              Development work will be done on branches. These
104 <              branches may only live for the period of the development
105 <              work. Once the work is complete and tested it will be
106 <              merged to master and the branch may be deleted.
107 <            </li>
108 <            <li>
109 <              The history on development branches may be rewritten to
110 <              tidy things up before merging. This probably won't
111 <              happen often, but don't get upset if it does.
112 <            </li>
113 <            <li>
114 <              If you want to submit changes it's best to do them
115 <              against the <code>master</code> branch unless you're
116 <              specifically working with a developer on an issue
117 <              already.
118 <            </li>
119 <          </ol>
78 >          <h3>
79 >            Git guidelines
80 >          </h3>
81 >          <p>
82 >            We've chosen a set of guidelines to work by so that
83 >            everybody is clear about how the Git repositories will be
84 >            used. This should make life easier for developers and
85 >            users. The aim is to keep things clear and simple without
86 >            adding unnecessary overheads. We don't have need for
87 >            anything as complex as git-flow.
88 >          </p>
89 >          <ol>
90 >            <li>
91 >              The <code>master</code> branch will always be buildable
92 >              and should be usable. Development work does not happen
93 >              here directly.
94 >            </li>
95 >            <li>
96 >              New releases will be taken from the <code>master</code>
97 >              branch and will be tagged there.
98 >            </li>
99 >            <li>
100 >              The master branch will never have its history rewritten.
101 >            </li>
102 >            <li>
103 >              Development work will be done on branches. These
104 >              branches may only live for the period of the development
105 >              work. Once the work is complete and tested it will be
106 >              merged to master and the branch may be deleted.
107 >            </li>
108 >            <li>
109 >              The history on development branches may be rewritten to
110 >              tidy things up before merging. This probably won't
111 >              happen often, but don't get upset if it does.
112 >            </li>
113 >            <li>
114 >              If you want to submit changes it's best to do them
115 >              against the <code>master</code> branch unless you're
116 >              specifically working with a developer on an issue
117 >              already.
118 >            </li>
119 >          </ol>
120          </div>
121   <!--#include virtual="/footer.inc" -->
122        </div>

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines