Skip to content

Branch and Commit Management

Bill Majurski edited this page Nov 23, 2016 · 5 revisions

Now that release v4.0.0 is released we have to manage branches and commits a little more formally. Basically there are two kinds of branches: new features and bug fixes. Here are the basic rules:

  1. New features are developed on feature/* branches as we have been doing. The branch if created off of develop and merged back there later. When merged the branch is deleted. If the work is not complete, then the branch can be re-created with the same name to hold the continuing work. If you are working on two features please keep them separate. By keeping them separate you don't have to guess ahead of time which one will be ready for merge and possibly release first.

  2. Bug fixes are developed on bugfix/* branches. Bugfix branches are created off master. When complete they are merged back onto master and onto develop so the fix is carried forward. Bugfix branches are named for the problem they fix, so bugfix/repoId is a possible name. They are not named for release numbers. When one or more bug fixes are complete they are merged onto master (and develop) for distribution and the branch is deleted. More than one bug fix can be included in a bug fix release.

  3. We are using semantic versioning. Our current version is 4.1.0 so the next feature release would be 4.2.0 and if we had to put out a bug fix release before that it would be 4.1.1.

  4. Do not add new features in bug fix branches. What is the difference? If you are fixing something that is not right, whether it has been reported or not, it is a bug fix - and...

  5. Each bug fix and new feature is recorded in the github tracker. The commit that fixes it should have its comment start as shown below. With this format, git will automatically mark the event as completed when this commit is moved to the master branch. Users actually look through the tracker.

    Fixes #234 - comment

  6. A new feature branch can include bug fixes if they can wait for the next release. Just make sure to document them properly in the commit message.

  7. Commit messages - this is the important part - With each release comes release notes. The only documentation I have to generate release notes from is your commit messages. In writing them think about the user of the tool as the audience, not yourself or me. It would help me a lot if commit messages could be copied directly into the release notes.

I can create the bug fix branches for folks and do the merges as I've done in the past.

Clone this wiki locally