ViewVC Help

View File | Revision Log | Show Annotations | Revision Graph | Root Listing

root/i-scream/web/www/git.xhtml

Comparing web/www/git.xhtml (file contents):
Revision 1.3 by tdb, Mon Jul 15 22:15:54 2013 UTC vs.
Revision 1.5 by tdb, Sun Aug 4 14:47:10 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	>	<li>
120	>	Gratuitous merge commits should be avoided, particularly
121	>	when merging development branches to <code>master</code>.
122	>	They don't offer much in the way of useful information
123	>	and make operations like bisect harder. In particular,
124	>	if you pull changes to your local repository and end up
125	>	with a merge commit you should use rebase to get rid of
126	>	it before pushing.
127	>	</li>
128	>	</ol>
129		</div>
130		<!--#include virtual="/footer.inc" -->
131		</div>

Diff Legend

–	Removed lines
+	Added lines
<	Changed lines
>	Changed lines