Last modified 7 years ago Last modified on 11/01/2011 01:17:16 PM

TCT proposal: Switch from Subversion to Git for Version Control

copied from email proposal

Proposer: Mario Juric

Based on the discussion at the git tutorial session held on Friday, Oct. 28th 2011, as well as the discussion on Nov 1st. 2011 DC3 telecon, I propose to switch to git as the version control system for LSST software. The rationale for choosing git is described as part of the Git Tutorial.

I also propose to define the following development workflow that mimics the existing one for svn:

  1. Anything in the 'master' branch is deployable (that is, ready to be tested in weekly runs and expected to pass all unit tests). Developing directly on the master branch is not allowed.
  1. 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.

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.

  1. When the feature is ready, ask for it to be reviewed. Some minor features may not need a review.
  1. 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.

For 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).