Branching strategies and github usage in our code

At Operaevent we have two branching strategies: one indeed is based on master, where master is the main stable branch and feature branches are being created and merged into master by all the developers. This is the case in `bounties-frontend` repo, where the main branch is master.

The other strategy is a variation of semantic versioning, where we have version in the format x.y.z (major.minor.patch), and 0.x.0 are stable branches where highest x is the latest code running in production. Particularly on `node` codebase we are on branch 0.5.0 right now, and at `gather-chrome` we’re on 0.1.0.

  • For now, our semantic versioning offers several advantages: (1) sorting branches alphabetically makes very good sense and we can handle dozens of branches without confusion, and (2) you always know what’s running in production and can fallback to an earlier version easily. Additionally, this methodology alleviates the need for creating release tags.

We have daily deliverables! This means that at the end of your day, you should commit your code and everything that you have written in the day, and preferably issue a pull request.

If you have not worked on a codebase for a while, branch off of the most recent branch (0.x.0) and pull request into it at the end of the day.

The work flow for our code repos, particularly gather-chrome, is as follows:

  • branch off of the most recent stable branch 0.x.0
  • pull request into it at the end of the day.
  • specs are optional right now, but will eventually be required. Specs now earn you bonus points.

While you are working on an issue, mark it as assigned to yourself in github issues. I encourage you to work on one issue at a time. Finish an issue, pull request it, and assign the next issue to yourself.

Leave a Reply

Your email address will not be published. Required fields are marked *