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