diff options
Diffstat (limited to 'HACKING')
| -rw-r--r-- | HACKING | 53 |
1 files changed, 16 insertions, 37 deletions
@@ -103,37 +103,22 @@ latest stable version of Autoconf installed and available early in your PATH. -* The git tree currently carries a number of branches: master for the - current development, and release branches named branch-X.Y. The maint - branch serves as common ground for both master and the active release - branches. Changes intended for both should be applied to maint, which - should then be merged to release branches and master, of course after - suitable testing. It is advisable to merge only after a set of related - commits have been applied. - -* Example work flow for patches to maint: - - # 1. Checkout the "maint" branch: - git checkout maint - - # 2. Apply the patch(es) with "git am" (or create them with $EDITOR): - git am -3 0*.patch - # 2a. Run required tests, if any ... - - # 3. Merge maint into branch-1.11: - git checkout branch-1.11 - git merge maint - # 3a. Run required tests, if any ... - - # 4. Redo steps 3 and 3a for master: - git checkout master - git merge maint - # testing ... - - # 5. Push the maint and master branches: - git push --dry-run origin maint branch-1.11 master - # if all seems ok, then actually push: - git push origin maint branch-1.11 master +* The Automake git tree currently carries two basic branches: 'master' for + the current development, and 'maint' for maintenance and bug fixes. The + maint branch should be kept regularly merged into the master branch. + It is advisable to merge only after a set of related commits have been + applied, to avoid introducing too much noise in the history. + +* There may be a number of longer-lived feature branches for new + developments. They should be based off of a common ancestor of all + active branches to which the feature should or might be merged later. + in the future, we might introduce a special branch named 'next' that + may serve as common ground for feature merging and testing, should + they not yet be ready for master. + +* After a major release is done, the master branch is to be merged into + the maint branch, and then a "new" master branch created stemming + from the resulting commit. * When fixing a bug (especially a long-standing one), it may be useful to commit the fix to a new temporary branch based off the commit that @@ -141,12 +126,6 @@ the active branches descending from the buggy commit. This offers a simple way to fix the bug consistently and effectively. -* There may be a number of longer-lived feature branches for new developments. - They should be based off of a common ancestor of all active branches to - which the feature should or might be merged later. The next branch may - serve as common ground for feature merging and testing, should they not - be ready for master yet. - * For merges from branches other than maint, prefer 'git merge --log' over plain 'git merge', so that a later 'git log' gives an indication of which actual patches were merged even when they don't appear early in the list. |