A web app for the algerian red crescent
Le projet consiste en la création d un site internet sur lequel serait lister les hôpitaux d'Alger dans un 1er temps ensuite peut-être tous les hôpitaux d'Algérie où on peut faire un don de sang, sur le site y aura la liste des hôpitaux donc et en cliquant sur le nom de l'hôpital ça nous envoye sur google maps avec la localisation exacte de l'hôpital
Ce là est dans le but que plus tard on mettra un qr code qui renvoie vers ce site sur la carte de remerciement remise aux donneurs voir même sur les flyers de sensibilisation
- Génrer les donneurs du sang
- Relie les demandes/donneurs
- Prioritizer les demandes / hopitaux par groupe siguin .. etc
We are using the githhub workflow to mangage the branching model, See here for more details: http://scottchacon.com/2011/08/31/github-flow.html
In a nutshell the github workflow consists of the follwoing main points:
- Anything in the
master
branch is deployable - To work on something new, create a descriptively named branch off of master (ie:
new-oauth2-scopes
) - Commit to that branch locally and regularly push your work to the same named branch on the server
- When you need feedback or help, or you think the branch is ready for merging, open a pull request
- After someone else has reviewed and signed off on the feature, you can merge it into master
- Once it is merged and pushed to
master
, you can and should deploy immediately
We can (for the begging) ignore the deployement process, then we could add CI/CD jobs.
Commit messages should as clear as possible and should follow the syntax and guidlines bellow bellow:
- Separate subject from body with a blank line
- Limit the subject line to 50 characters
- Capitalize the subject line
- Do not end the subject line with a period
- Use the imperative mood in the subject line
- Wrap the body at 72 characters
- Use the body to explain what and why vs. how
<TYPE>[<SCOPE>]: <Title>
// Blank line
Message
Where <TYPE>
could be:
Feat
- feature, new functionalityFix
- bug fix, not adding anything new, but rather removing "unwanted feature".Refactor
- refactoring of production code. This type of commit should not have an impact on end-user experience at any point. The application's behavior should remain the same, and only the refactoring is applied.Style
- code style improvements, like changing::a => :b
toa: b
, or double quotes to single ones, Without any changes in the app's behaviorDoc
- documentation changes. That include README updates and any other documentation-specific things.Test
- test coverage improvements
and <SCOPE>
could be the file/files name/names or any readable name that has a meaning for all othe developpers.
Examples:
Doc[README]: add contiributing rules and guidlines
Fix[backend]: fix hospitals lookup api
- Clone repository
- cd red-crescent-webapp
- npm install
- npm start