couchdb-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Couchdb Wiki] Update of "Merge_Procedure" by RobertNewson
Date Tue, 08 May 2012 08:58:46 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Couchdb Wiki" for change notification.

The "Merge_Procedure" page has been changed by RobertNewson:
http://wiki.apache.org/couchdb/Merge_Procedure?action=diff&rev1=8&rev2=9

Comment:
some details on git handling

  If the ticket was COUCHDB-1234, and the ticket title was My Cool Feature, your branch should
be called `1234-cool`.
  
  == Git Best Practice ==
+ 
+ Developers are free to use a feature branch in any way they see fit during development.
Prior to submitting a merge request to dev@, though, the branch should be prepared according
to the following rules, as the commits on the feature branch will be a permanent part of the
couchdb project's history.
+ 
+ A feature branch should consist of the smallest number of meaningful commits as possible.
For bug fixes and small features, this is likely to be a single commit. For larger changes,
multiple commits might be necessary. The guiding principle for deciding how many commits is
coherence. A commit should be readable and, ideally, implement one distinct idea. A feature
that requires multiple enhancements to achieve its goal should be presented as multiple commits.
It is *not* necessary for the system to pass the test suite for any subset of these commits,
only their combination.
+ 
  
  '''@@ BOB, PLEASE LET ME KNOW IF YOU WANT A DIAGRAM MAKING FOR THIS SECTION.'''
  
@@ -155, +160 @@

  
  Follow these instructions to merge a feature in to one release branch.
  
- '''@@ BOB, PLEASE CREATE IN A LIST OF INSTRUCTIONS, INCLUDING COPY AND PASTE GIT COMMANDS,
HERE.'''
+ Feature branches are merged to release branches using 'git merge --no-ff <FEATURE BRANCH>'.
This guarantees a merge commit, which are the only kinds of commit that will appear on release
branches. If the merge results in conflicts, the release manager rejects the merge commit
with an reply to the dev@ thread. If the merge is successful, the release manager should run
'make distcheck' and push the merge upstream if the tests pass. 
  
  == Bugfix ==
  
  Follow these instructions to merge a bugfix in to multiple release branches.
  
- '''@@ BOB, PLEASE CREATE A LIST OF INSTRUCTIONS, INCLUDING COPY AND PASTE GIT COMMANDS,
HERE.'''
+ For each release branch, 'git checkout <RELEASE BRANCH>' and 'git merge --no-ff <BUGFIX
BRANCH>'. If any of the merges fail, the merge request is rejected.
  
  == Security ==
  
@@ -169, +174 @@

  
  (Security fixes can be merged in to supported release branches just like bugfixes.)
  
- '''@@ BOB, PLEASE CREATE A LIST OF INSTRUCTIONS, INCLUDING COPY AND PASTE GIT COMMANDS,
HERE.'''
- 

Mime
View raw message