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.
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.
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.
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
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.
How'd We Do?
Was this article missing something?
Was it not quite what you were looking for?
Do you have suggestions on how we could improve this article or your experience in general?
If so, please take a moment to let us know!
Your invaluable feedback will help everyone better understand the platform!