Changes between Version 15 and Version 16 of StartModMaint


Ignore:
Timestamp:
Dec 10, 2013, 1:59:04 PM (9 years ago)
Author:
Beman Dawes
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • StartModMaint

    v15 v16  
    117117=== Start work on a new feature ===
    118118
    119 Developers are encouraged to create a (possibly private) branch to work on new features, even simple ones, since development of new features on the {{{develop}}} branch might leave it unstable for longer that expected. Using the Git Flow convention, the branch will be named {{{feature/add-checksum-option}}} and {{{--track}}} is used instead of {{{-b}}} to ensure a public branch.
     119Developers are encouraged to create a (possibly private) branch to work on new features, even simple ones, since development of new features on the {{{develop}}} branch might leave it unstable for longer that expected. Using the Git Flow convention, the branch will be named {{{feature/add-checksum-option}}}.
    120120
    121121{{{
    … …  
    124124}}}
    125125
    126 The usual cycle of coding, testing, and commits then begins. If other work needs to be done, a {{{stash}}} or {{{commit}}} may be done to save work-in-progress, and the working copy switched to another branch for awhile. If significant fixes or other enhancements have been made to {{{develop}}} over time, it may be useful to merge {{{develop}}} into the feature branch so that the eventual merge back to {{{develop}}} has less conflicts. Here is how the merge from {{{develop}}} to {{{feature/add-checksum-option}}} is done:
     126 Public or private? When you create the branch, or perhaps later, you may decide the branch should be public (i.e. be present in the public boostorg repo) so that you can share it with others or just to back it up. Set that up by running:
     127
     128 {{{
     129git push origin feature/add-checksum-option
     130}}}
     131
     132The usual cycle of coding, testing, commits, and pushes (if public) then begins. If other work needs to be done, a {{{stash}}} or {{{commit}}} may be done to save work-in-progress, and the working copy switched to another branch for awhile. If significant fixes or other enhancements have been made to {{{develop}}} over time, it may be useful to merge {{{develop}}} into the feature branch so that the eventual merge back to {{{develop}}} has less conflicts. Here is how the merge from {{{develop}}} to {{{feature/add-checksum-option}}} is done:
    127133
    128134{{{
    … …  
    131137}}}
    132138
    133 == Merging to {{{master}}} for the First Time ==
     139== First post-conversion merge to {{{master}}} ==
    134140
    135 When you are ready to merge either the develop branch, or better yet a release branch that's forked off from develop), there's a bit of housekeeping to be done
    136 the first time (assuming your library was originally in SVN) so that future merges proceed smoothly.  We're going to create a merge point between
     141When you are ready to merge the {{{develop branch}}} to {{{master}} (or better yet a release branch that's branched off {{{master}}}), there's a bit of housekeeping to be done
     142the first time after the conversion from svn so that future merges proceed smoothly.  We're going to create a merge point between
    137143the develop and master branches so that Git knows the last point the two branches were in synch.  Once we've done that Git will perform a merge by
    138144replaying the commits on develop on top of master, starting from the last known merge: in other words Git will perform the tricky stuff of figuring