Summer 2021 group project for the module "Advanced Programming" of the Engineering Business Information Systems B.Sc. program at Frankfurt University of Applied Sciences.
- Anton Roesler
- Patrick Frech
- Leonard Hußke
- Feng Yi Lu
- Christine Kaderka
- Benedikt Möller
- Before a new feature is developed or a change is made, there must be an issue. If there is no issue: open one. The issue is so that everyone else knows what is happening and can comment on it. Everyone should actively participate in the communication.
- For a new feature, create a new local branch - never work on the main branch. Once the feature is ready and the code works, create a pull request. (See GIT workflow)
- Your code should be cleanly written and commented as needed.
- Your code should be well tested before creating a pull request.
- Naming conventions and other style specifications are still to be announced. For JavaScript code, the naming conventions according to https://www.robinwieruch.de/javascript-naming-conventions should be used.
- A feature should always have its own branch, no two new features in one branch. 2.Naming rule for a commit is #issue Here is a short description e.g. #1 Initial commit. A branch should always contain the feature name and should be descriptive e.g. test/foo. Test is a leading token for categorization. More leading tokens are: feat, bug, test, wip.
- Clone the project to the local machine.
- Creating a branch to develop a feature, debug, test, ...
- You then start to work and commit your changes to the new branch. And publish the branch to GitHub.
- When you're done, create a pull request on GitHub to contribute your code to the main branch.
Before you start coding, create a header comment in the new file you created. It is important to think about WHAT you are doing before you start coding. You can find an example header in the misc folder under header.txt.