-
Notifications
You must be signed in to change notification settings - Fork 0
Git Workflow recommendations
Recommendations on how to use the Lacuna-Server (LS) and the Lacuna-Server-Open (LSO) git repositories.
These recommendations are based on best practices from the following, and other, sources.
- http://nvie.com/posts/a-successful-git-branching-model/
- http://blog.hasmanythrough.com/2008/12/18/agile-git-and-the-story-branch-pattern
The LSO repository should be considered the definitive repository and the LS repository should only pull from LSO, never the other way around. This will ensure that no sensitive data held on the LS repository can ever leak out into the public domain.
There will be a number of branches with 'infinite' lifetimes.
- master (on LS and LSO)
- pt (LS only)
- us1 (LS only)
- develop
The origin/master branch should hold the latest release of The Lacuna Expanse server code.
The origin/us1 and origin/pt branches should be branches which match the master branch in all specifics, except that they include some server dependencies (e.g. in the etc directory).
The origin/develop branch will be used to integrate all development scheduled for the 'next' release of code.
When the origin/develop branch reaches a stable state then it is merged into origin/master which is in turn merged into origin/pt and origin/us1
This means that whenever code is merged into origin/master it is, by definition, a new release to production.
The origin/pt should always be at the same state as origin/us1 so that if, at any time, we wish to reproduce a bug found on the production system we can do so by simply checking out the origin/pt code onto the PT server and know that we have the same code. This is in comparison to the current practice where origin/pt can hold some future unstable development version of the code.
The document http://nvie.com/posts/a-successful-git-branching-model/ should be used as a reference to managing release versions, applying hot fixes and branch naming conventions.