g. for ticket
#29 we could call our branch feature-29 or feature-29-add_spell_checking and
our commit log would be something like "Branched to add spell checking. See
ticket #29.". As we are developing something new, our branch should be made
from the HEAD revision of the trunk.
Now we can finally do what we do best??”develop??”safe in the knowledge that:
1. We know exactly what we are supposed to be doing.
2. What we are doing is not going to affect anyone else until we merge.
Since we are working in our own branch, we can commit our changes as often as we
like and we should take advantage of this. The only rule is that we have to commit
prior to merging the changes back into the trunk. The decision to merge should
be based on one question only: is the feature complete? If the answer is positive, we
should stop coding, commit and merge. We should not be tempted to overdevelop
a feature or re-use a branch??”once we have merged into the trunk and committed
the changes, then the branch should be discarded or even deleted. As with the
branch log, the merge log should make reference to the feature ticket number e.g.
"Addresses ticket #29 by implementing spell checking.".
What about code reviews?
Code reviews are a good thing, and if we do not have them in place
already then we should.
Pages:
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107