Contribute Code

If you have a WebLinc Stash account and permission to access the Workarea source code repositories, you may contribute code to the platform in the form of pull requests. Pull requests are often submitted to fix bugs discovered during implementations or to push improvements made during implementations upstream. Pull requests to improve documentation are also common. Whatever type of improvement you'd like to submit, thanks! This document should help you on your way.

Pull Requests

Squash your commits and rebase against the branch that you will merge into, so that your topic branch is exactly one commit ahead of the long running branch. This allows your changes to be easily cherry-picked for additional pull requests and keeps the commit log clean.

Commit Messages

Write your commit message as if it will be used as an entry in the changelog. Consider your audience: systems integrators upgrading to a new version of Workarea.

Follow the seven rules of a great git commit message. Use Markdown for text formatting, such as marking up a list or delimiting code (see example/template below).

Include the JIRA issue key(s) (if any) on the last line(s) of the commit message.

Note: In the event your commit is not relevant to readers of the changelog, omit the JIRA issue key or include the string "No changelog" within the commit message.

Commit Message Example/Template

Summarize changes in around 50 characters or less

More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of the commit and the rest of the text as the body. The
blank line separating the summary from the body is critical (unless
you omit the body entirely); various tools like `log`, `shortlog`
and `rebase` can get confused if you run the two together.

Explain the problem that this commit is solving. Focus on why you
are making this change as opposed to how (the code explains that).
Are there side effects or other unintuitive consequenses of this
change? Here's the place to explain them.

Further paragraphs come after blank lines.

* Bullet points are okay, too.

* Use an asterisk for the bullet.

* Keep bullets flush left. Line breaks between bullets are optional.

Put the JIRA key on the last line, like this:

ECOMMERCE-4321
Fixes: ECOMMERCE-1234

Reviewers

Push your topic branch to origin. The confirmation message will include a URL to create a pull request in Stash. Confirm the topic and long running branches are correct and create your pull request. Add as many developers you would like as reviewers, but at least one of them must have permission to merge your topic branch into the appropriate long running branch.

Denied Pull Requests

Most denied pull requests can be re-opened and resubmitted with the necessary changes to be accepted. Please re-open the same pull request rather than creating a new one so that the feedback from reviewers is preserved. Before re-submitting the pull request, please remember to rebase and squash again, following the guidelines above. It's perfectly acceptable to force push changes to a topic branch in this scenario.