On Sat, Aug 30, 2008 at 09:44:37AM -0700, Ben Pfaff wrote:
OK, how about this then:
- The "master" branch we are currently using remains the
primary development branch. Anything that introduces a
new feature is committed to this branch.
- We create a new branch, tentatively named "stable", and
initially branched away from where "master" is now.
Anything that fixes a bug is committed to this branch.
- Periodically, as necessary, we merge the stable branch
into the master branch, so that the master branch also
receives bug fixes.
Comments?I'm still comming to terms with git, but SCM tools I've worked with in the past normally make it possible to have a branch which *automatically* inherits changes which are commited to its parent (ie the thing it branches from). Isn't this possible with git? That's why my prefered option was to do the opposite of what you're suggesting: The "master" branch (what I normally call the "trunk") is the bug fix branch, and a new branch becomes the primary development branch. That way, the periodic merges aren't required --- bug fixes are automatically in the development branch by virtue of the latter's inheritence of the former. Perhaps I'm totally misunderstanding how git works. J' -- PGP Public key ID: 1024D/2DE827B3 fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3 See http://pgp.mit.edu or any PGP keyserver for public key.
signature.asc
Description: Digital signature
_______________________________________________ pspp-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/pspp-dev
