- Quick Start
- Enstore Git Flow Tutorial OLD - run git flow against test repository
- Enstore Git Flow Tutorial 2 [in progress] - run git flow against production project repository
- git subtree and Enstore subprojects
- git subtree
- git flow Workflow and Branching Model
- Git commands for CVS users
- clone enstore source tree
- install and initialize 'git workflow' in your repository
- rebuild git subtree if you need to support enstore dependencies like ftt and commit code upstream
git subtree and Enstore subprojects¶
CVS repository has several modules to keep Enstore code and dependencies. It also contains configuration files used in production system.
We follow this structure and also copied configuration files to separate repository. We split project into three sub projects as different people will access the code.
In Redmine the project can have subprojects. Each subproject can have multiple repositories.
enstore - this is where all enstore code resides, including dependencies merged with git subtree
core - the core enstore code. This is enstore2 CVS module converted to git.
this is enstore2 module in CVS directly accessed by redmine.
- Fermi Tape Tools module converted to git
- project:enstore-deps - several OpenSource projects. code converted from CVS module to git repository
enstore-config - we split selected configuration files from enstore/etc into enstore/config directory to be managed by SSA
git has 'modules' but reportedly there are some issues with that, you may look for discussion elsewhere.
We use 'git subtree' contributed project to git project. It comes with git distribution but it needs to be rebuild separately.
git subtree works in way that we 'merge' external "module" like ftt (or htmlgen,...) as directory in core enstore tree (like /opt/enstore), and all files from all subtrees present when you do clone or pull.
We did merge once and do not expect to do 'split' and 'merge' very often. As a practical matter we will work with the merged code in 'main' enstore repository and use repositories for dependencies if we need to push code upstream.
We do not do modifications to subtrees very often. When there is need for such modification, we can 'split' subproject and contribute changes to upstream project.
The documentation suggests to avoid committing files from different subtrees in the same commit. Please do separate commit to each subtree. This will allow cleanly separate commits and history to different subtrees, like to enstore and ftt.
We used git subtree to split enstore configuration files into separate repository. git subtree operates with subdirectory, therefore we put (copied) configuration files into separate "config" directory where SSA can modify files.
git flow workflow¶
historically enstore team kept the 'production' releases on cvs trunk and tagged pristine code approved in code review with cvs tag 'production.' That version of code was tagged too as enstore release when code is released and rpm built.
We found there is git workflow model close to what we used with cvs and there is implementation as a set of git scripts.
We will keep 'pristine' code on develop branch and the final product leave on production branch with proper tags as release numbers.
During git flow initialization it is possible to select different names of branches, it suggests few as a choice, we use 'production' to name production branch.
When reading gitflow presentations and documentation please substitute "master" branch by "production."
See more details at page Git Flow
- Vincent Driessen, "A successful Git branching model." Substitute "master" branch by "production" when reading.
- Git Intro http://gitref.org
- Git visual cheat sheet:
- Documentation at git home http://git-scm.com
- Git wiki https://git.wiki.kernel.org
- Git community book http://book.git-scm.com/
- John Wiegley, "Git from the bottom up."
Nice brief and simple writeup how things work internally, it makes understanding high level git commands much easier.