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> |
120 |
|
</div> |
121 |
|
<!--#include virtual="/footer.inc" --> |
122 |
|
</div> |