...
| Table of Contents | ||||||
|---|---|---|---|---|---|---|
|
1. Fork
Wherever you want to implement a new feature or to fix a bug the only way to contribute is to fork the project in your userspace (in GitHub is called https://github.com/<username>) and to Pull-Request on from an ad-hoc branch different from the 'develop' (if not available please ask on Jira OpenHospital page to open one for you).
In order to fork, go to the develop branch page and component’s page of your interest and click on "Fork" on the right-top.
...
...
Open Hospital components are:
Issues generally contain indications about exactly “which” components will be affected
...
2. Clone
Once forked, you need to clone your fork on your local repository (your computer) using Git command line or any IDE with Git support (Eclipse, NetBeans, Intelli-J, etc...) using the provided info from the component’s page:
git clone <copied_URL_from_GitHub>
cd <cloned_component_name>
3. Branch
Once cloned (or synced), create and switch to the an ad-hoc branch related to your task issue and start coding!
git checkout -b <my_feature_branch_name>
Branch naming convention is <issue code>-<issue_or_solution_title>, you can ask Jira to produce one for you (e.g. OP-962-session-table-for-log):
...
In this way, your developments will be automatically linked to Jira, and also issues’codes typed in GitHub will be converted into links to Jira’s pages.
...
NOTE: use the same branch name for all repositories involved in the issue
4. Code
On your "forked-and-cloned-branchthen-branched" you can commit as many times you want, but please follow the 'gold rules' below.
Check our Coding Chips!
Double analyze the existing code, don't write what is already written, be DRY (Don't Repeat Yourself)
Dumb code is better than clever one when is time to share
Write comments when only "YOU" know what you are doing
Optimize only after achieved
Less is more!
5. Push
Once finished, tested and ready to share, it's time to push!
By pushing you will reflect your commits on your online fork. After that you can ask a pull-request toward the ad-hoc branch on the original repository.
For better understanding the above and others Git terms you may be helped by
...
this graphical view:
...
6.
...
Please refer to Java Spring pattern (see Spring Migration) and use Smart Commits (track your time) as much you can.
If you need to resync your fork because too old, please follow Git fork syncing (polish your work)
Coding chips!
| Child pages (Children Display) | ||||||
|---|---|---|---|---|---|---|
|
We need you!
The ticketing version doesn't change anyway: you can contribute through bugs-fixing and feature-requests or even answering to new support-request coming from new users. In order to avoid different devs work on same issues, we kindly ask you to inform us so the task can be assigned to you.
And don't forget the 'gold rules'!
...
Fork, develop & merge-request (pull-request)
...
Double analyze the existing code, don't write what is already written, be DRY (Don't Repeat Yourself)
...
Dumb code is better than clever one when is time to share
...
Write comments when only "YOU" know what you are doing
...
Optimize only after achieved
...
Open a Pull Request
Once pushed back to your online fork, it’s time to open a Pull Request in order to get your code reviewed and applied to the official repository
Insert a thorough description in the Pull Request, indicating again the issue code (to easy link to Jira issue’s page), some useful info and whereas the PR is linked to another PR on another component.
...
7. Communicate
Comment and ask on the Jira issue’s page about suggestions, reasonings, findings and to update the community about your job. Be respectful and foster others in sharing their thoughts.
You can reach out to the community of contributors by joining our Slack workspace or by subscribing to our mailing list.
...
8. Stay tuned!
Very important, keep an eye on reviews and comments on your Pull Requests pages.
A Pull Request will NOT be merged (welcomed) until there will be unresolved conversations.
...
Keep also an eye on new developments landing on the component’s develop (default) branch and periodically resync your fork!
For more info see Git fork syncing (polish your work)
Thanks and happy coding!