| 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> |
