OSM Aviation

Version Control

All our projects use Git, mostly with a repository hosted on GitHub.

Repo naming conventions

All repositories should be named after the product they contain. This can be done in numerous ways, but generally we don't want the URL of the product as the repository name.

  • Bad: portal.osmaviation.com
  • Good: portal

Branches

Once a project is in production there is one thing you must remember: The master branch must always be stable. It should always be safe to deploy the master branch to production at any given time. All branches are assumed active; stale branches should be cleaned up accordingly.

Projects in initial development

Projects that are not yet put into production should contain at least two branches; master and develop. Avoid committing directly on the master branch, always commit through develop.

Feature branches are optional, but if you create one, please branch it from develop, not master.

Projects in production

Once a project is in production the develop branch must be deleted. All future commits to master must be added through a feature branch.

There's no strict rule on feature branch names, just make sure the name of the branch is clear enough to know what they're for. Branches may only contain lowercase letters and hyphens.

Features should be prefixed with feature, and bug fixes with fix. For changes that are made in bulk please include the month and year in your branch name.

  • Bad: feature/mailchimp, random-things, develop
  • Good: feature-mailchimp, fix-specificthing, updates-february-2018

Pull Requests

Branches are only merged via pull requests. The pull request should include a short, but descriptive, title and a description.

If the new code requires configuration please include this in the description field. Consider it being a README for anyone reviewing your code.

Bad:

I fixed everything

Good:

This PR addresses the current issues in assessment day raised in Trello (link to card).

Before merging, please add the following to the application environment:

FOO_BAR=baz

Before anything is merged there should be no merge conflicts and all tests should pass. Github will automatically check for merge conflicts, and our CI tool will run the tests after the PR has been created.

Once a feature has completed its development cycle, a PR should be opened to notify project lead/lead developer that the code is ready to be reviewed.

Commits

There's no strict rule regarding commit messages on projects in initial development. However, once in production always use descriptive commit messages. Please always used present rense in your commit messages.

  • Non-descriptive: wip, commit, fix, much code
  • Descriptive: Update deps, Fix the filter for nationalities

Ideally, prefer granular commits.

  • Accepted: Filter fixes
  • Better: Fix the filter button for cabin crew, Fix the update cycle on the filter base component

The OSM Aviation Portal

There are two main projects to considered when working on the portal; Crewmatch and Crewman. Both these projects have their own respective branches. You should always create a PR towards the branch of the project you are working on. An exception to this is for bugfixes. They should be created towards the master branch.

The branches crewmatch, crewman and master all have push protections and may only be pushed to by an administrator.

crewmatch and crewman are merged with master via a PR on a monthly basis. This PR should be opened two weeks prior to release plan. The description should be contain all new features and updates contained in the update. The title of this PR should follow the following template:

  • For crewmatch:

    • CREWMATCH Updates September 2018
    • Template: {PROJECT} Updates {MONTH} {Year}

  • For crewman:

    • CREWMAN Updates September 2018
    • Template: {PROJECT} Updates {MONTH} {Year}

← Deployment →