Repository Model

From Meridian 59 - Open Source Wiki
Jump to: navigation, search

Intro

This page introduces our official branching model for our Github repositories.

The entire model can be read about here: http://nvie.com/posts/a-successful-git-branching-model/

Git-model@2x.png

Repository Terminology

Upstream: OpenMeridian/Meridian59

Origin: Your Github Fork of OpenMeridian/Meridian59 (skittles1/Meridian59 is an example of Delerium's Origin)

Working: Your local git clone of your Origin repo

Branches Terminology

Master branch: The master branch is the branch that contains whatever code is running in production. Only Hotfix branches and the Develop branch may be merged here. Your Origin/master branch should always be kept in sync with Upstream/master and your Working/master branch should be kept in sync with Origin/master. Hotfix branches are created from the master branch. Develop branches are created from the master branch. The master branch persists and will always be named "master". Each merge to the master branch will be accompanied with a "tag" commit which preserves that spot in the branch history as a known version/state of code.

Hotfix branch: A hotfix branch contains code that is urgently needed to be applied to master, in order to fix a production level error. Nothing should ever be merged into a hotfix branch unless two people are coordinating on the hotfix. Nothing should ever use a hotfix branch as a parent. A hotfix branch will have a name like "hotfix-*" where * is the project version number. A hotfix branch will be removed after merge into master and develop.

Develop branch: The develop branch is the branch where integration takes place. Pull requests are targeted here. This branch is created from the master branch, and pull requests and hotfixes get merged here. Your Origin/develop should always be kept in sync with Upstream/develop and your Working/develop branch should be kept in sync with Origin/develop. Feature branches are created from the develop branch. Release branches are created from the develop branch. The name of the develop branch will always be "develop" and will persist, much akin to master.

Release branch: A release branch contains code that is ready for final testing before being accepted into the master branch. They are created from the develop branch, can be merged back into develop for additional work, or if all tests pass, can be merged into the master branch. A release branch will be named "release-*" where * is the project version number. A new release branch is created for each proposed release and removed after successful merge.

Feature branch: A feature branch is a branch or set of branches that contain specific features (a spell, a new system, modification to existing thing, etc.). They are created from your Working/develop branch and will eventually be used as a pull request to the Upstream/develop branch. Feature branches can have any name as long as it does not start with or equal "master", "develop", "release", or "hotfix" and can be deleted after they are accepted into the "develop" branch; however you may wish to retain copies on your Origin for future reference or future work.

Workflow Example

So, let's say you want to add a new spell:

  1. Fork OpenMeridian/Meridian59. This is your Origin repository. (Is probably done already for non-new devs)
  2. Clone your Origin repository to your local development environment with: git clone (this is probably done already for non-new devs)
  3. Switch to the develop branch with: git checkout develop
  4. Create your feature branch with: git checkout -b MyNewSpell
  5. Code the spell!
  6. Commit the changes: git add, git commit (which saves the changes to your Working repo in the MyNewSpell branch)
  7. Push the branch: git push (which sends the changes to your Origin repo in the (new) branch MyNewSpell)
  8. Open a pull request on github.com between Origin/MyNewSpell and Upstream/develop