Changes between Version 1 and Version 2 of DM/TCT/GitProposal


Ignore:
Timestamp:
11/01/2011 08:17:16 PM (8 years ago)
Author:
RayPlante
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • DM/TCT/GitProposal

    v1 v2  
    1313  2. Feature and bugfix development always happens in branches linked to trac tickets. The branches shall be named tickets/XXXXX where XXXXX is the Trac ticket number. It is advisable to commit often to ticket branches. This keeps others aware of your work, as well as serves as a form of backup. 
    1414 
    15   However, the master branch should ''not'' often be merged into the ticket branch.  Ideally, it should only be merged if a new feature appears in the master, and that feature is needed by the code of the ticket. This prevents complex-looking commit histories and makes debugging easier. 
     15  However, the master branch should '''''not''''' often be merged into the ticket branch.  Ideally, it should only be merged if a new feature appears in the master, and that feature is needed by the code of the ticket. This prevents complex-looking commit histories and makes debugging easier. 
    1616 
    1717   3. When the feature is ready, ask for it to be reviewed. Some minor features may not need a review. 
    1818 
    19    4. A feature that passes code review is permitted to be merged into master. Merge it using 'git merge --no-ff', to ensure a "merge" commit will be created. Once merged, *do not* delete the tickets/XXXX branch. 
     19   4. A feature that passes code review is permitted to be merged into master. Merge it using 'git merge --no-ff', to ensure a "merge" commit will be created. Once merged, '''''do not''''' delete the tickets/XXXX branch. 
    2020 
    2121For maintaining "stable" releases, a separate branch (e.g., "stable-R4.0") will be created. Exactly the same flow as described above applies to that branch, except that no new features are allowed (bugfixes only).