Git References
Git has many similarities to other source code version control systems, but there are important differences as well. There are a number of useful references to help you master your use of git:
git Reference -- read this first to get a high-level overview in 15 minutes
Learn.git series -- another git introduction, including screen-casts (note: the text may be somewhat more informative than the embedded screencasts)
http://git-scm.com/course/svn.html -- git for svn users (but please, read the links above as well)
Pro Git book -- Written by Scott Chacon. Get to know git in more depth (~2 hrs?)
Git Book -- similar to the Pro Git book, but a bit more comprehensive
Useful git tips -- some useful less well known tips
A cookbook style document, Git Crash Course, may help you understand the use of git for LSST/DM code development.
LSST DM code development is governed by various policies to maintain order in a large, distributed, multi-developer project. The policies are embodied in the workflows described below. Note: the branch management policy described here is drawn from the page: DM Branching Policy which is the authoritative source.
The following workflow is based on github-flow:
git rebase master"
). This prevents complex commit histories.--no-ff"
option, as described below). Jenkins and buildbot will notice and will build and test it (again).If a release date is approaching, a release integration branch may be created; only mandatory release fixes should go on such a branch (and usually be cherry-picked to master as well). Normal development on master will continue.
For maintenance on "stable" releases, a separate release maintenance branch may be created if necessary. Only bug fixes should go on such a branch (and again usually be cherry-picked to master).
An example workflow for developing a new feature is the following:
Verify which branch you are on. Ordinarily that would be the git master branch:
git branch or git status |
Create a new branch for ticket DM-9999, both locally and remotely:
git checkout -b tickets/DM-9999 git push -u origin tickets/DM-9999 |
Create or modify the source code. Commit often: Push periodically:
git commit -a git push |
After your code passes review, merge it into master:
git checkout master git pull master git merge --no-ff tickets/DM-9999 git push |
When creating tags meant for the public (e.g., release tags), always use annotated tags (that is, 'git tag -a
') or signed tags ('git tag -s
'). These store the information on who created the tag, when, can be cryptographically signed, and can have a message attached to them. For example:
git tag -a -m "Version 4.7.0.0" 4.7.0.0 |
or, with signing:
git tag -s -m "Version 4.7.0.0" 4.7.0.0 |
The following illustrates the sequence of operations one ordinarily executes with git during source code development.