Skip to content

Branches

Jump to bottom
anurse edited this page Mar 3, 2013 · 4 revisions

Here are the branches we used to develop the gallery.

Topic Branches

Topic branches are the branches in which work is done. They should be named with the Issue Number clearly visible (for example: "Bug-1234"). Including your username also helps to identify who "owns" that branch. All work must be done in topic branches. Topic branches should live until the feature is deployed to Production. Once deployed, the topic branch can be deleted.

Merging in Topic Branches

Topic branches should ALWAYS be merged using non-fastforward merges. The reason for this is that it effectively "collapses" your commits down to a single entry in the main branch, allowing it to be easily removed if we need to take it out of a deployment.

The dev-start Branch

This branch represents the starting point for an iteration of dev work. All topic branches should be created from this point. It is essential that topic branches start from here to ensure features remain as isolated from each other as possible and to allow them to be easily removed from deployments when test issues arise.

The dev Branch

This branch represents the merged content of the feature work devs are working on. It is the plan for the next preview deployment. However, since topic branches should remain alive, this branch can be easily discarded and rebuilt from dev-start and a collection of topic branches in order to remove features from a deployment.

The Deployed Branches

The preview, staging and master branches represent the code on "preview.nuget.org", "staging.nuget.org", and "nuget.org" respectively. They should always be advanced using fast-forward merges.

Making a fix to a Deployed branch

Sometimes issues will arise during integration testing and fixes will need to be made directly to one of the integrated environments. If that needs to happen, follow this process:

  1. Create a separate issue for the fix (even if there is one for the feature in which the bug has arisen).
  2. Create a topic branch off of the deployed branch in question (i.e. preview) for that issue
  3. Make the fix
  4. Submit a pull request against the deployed branch
  5. Merge the fix in to the deployed branch via a non-fastforward merge
  6. Merge the fix in to dev via a non-fastforward merge

Occasionally the fix will be small enough and urgent enough that we can't/don't want to wait for a code review before merging in to the deployed branch. In this case, merge directly into the deployed branch and send a pull request to merge the change in to dev. That way, we can do the code-review on the less-urgent process of merging in to dev

Clone this wiki locally