Skip to content

Source Control

Jump to bottom Edit New page
Walt Wells edited this page Sep 28, 2017 · 5 revisions

We are using GitHub for maintaining issues and specification for PFA, along with branches for approved resolutions and working proposals. We maintain two kinds of branches:

Master Branch

A single master branch (named master) where the release manager prepares the upcoming version.

Approved Branches

A separate branch is created and maintained for each released version. This is where all approved proposals for that particular version are merged. Such a branch stems from the latest version of the master branch and is named with the version number followed by the suffix -approved.

In order to reap the benefits of using the source control system, different versions of each file should be easily diff-ed and compared. For this reason, it is critical that checked in files use consistent formatting.

Version control

The PFA Working Group will use feature branch workflow for development workflow, with release process following this post.

  1. Developer A creates a feature/fix/chore/doc branch, do development there.

  2. Feature completed, make a pull request, developer A should also squash redundant commits before merge. If this pr is created for a github issue, you should create the pr with resolve issue #XX in the description.

    To squash your latest 3 commits, you can git rebase -i HEAD~3, then choose which commit to squash.

  3. The release manager will review the code, make comments, then give a final sign off

  4. Developer A merge to master, and click "Delete branch"

    Before merging your branch, if there is another developer merged it and now your branch has conflict, you can:

git checkout master
git pull origin master
git checkout feat/branch
git pull origin feat/branch
git rebase origin/master
git push -f origin feat/branch

Pull Requests

  • Put "[keyword] [issue number]" in pull request descriptions.
  • Describe what you changed in this pull request
  • Connect pull requests to issues

Commit Messages

[(Details here.)][2]

The format is:

<type>(<scope>): <subject>

<body>

<footer>
  • Allowed <type>:
    • feat
    • fix
    • docs
    • style
    • refactor
    • test
    • chore
  • Allowed <scope>:
    • Anything specifying the place of the committed changes.
  • <subject> text:
    • Imperative present tense
    • First letter not capitalized
    • No period at the end

Review

An issue is only considered finished if it's merged. So leave enough time for review and 1~2 iteration of further developments after review.

Add a custom footer
Add a custom sidebar

Clone this wiki locally