Skip to content

Instantly share code, notes, and snippets.

@stwiname

stwiname/Sylo Developer Guide.md

Last active May 9, 2018 21:18
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save stwiname/07d1daf2a9feda14fed473e365ec133b to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save stwiname/07d1daf2a9feda14fed473e365ec133b to your computer and use it in GitHub Desktop.
Download ZIP
Raw
Sylo Developer Guide.md

The Sylo Developer Guide

Branching

Naming

Branch names should take the format [type]/[name].

The type is what the purpose of the branch is, is it a fix or a feature or something else?

The name is what it does. If its a fix then what does it fix. If its a feature then wat is the feature. The naming convention for this should be lisp-case

Examples:

  • feature/i18n
  • fix/autocorrect-issue

Strategy

We aim to follow this strategy:

  • master is the latest published/deployed code
  • development should be the working branch
  • Other branches are branched off development and merged back into development

Pull Requests

  • Should be a managable size for reviewers
  • Should achieve one thing
  • Pull requests should be rebased by the creator before being reviewed
  • Responding to pull requests should be a high priority. For more explanation read this article
  • Developers should not merge their own pull requests

For Sylo-Mobile this template should be used

Naming

  • Prefix with [WIP] if the PR is not yet ready to be merged
  • Should be short and have some relevance to the banch name

Versioning

semver should be used for all versioning

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment