Code Structure and Group Process Milestone 4

We have the master branch and our beloved frontend and android branches for holding the best code from each user-faced subteam. There are also feature branches and issue branches.

Front-End

In front-end team, we treat the frontend branch like it is our master branch. We have a deployment for it, so we can see our subteam's status at all times. We use feature and issue branches and create a pull request from another member, so every code is checked and reviewed. Our process is working well so far. We're using ant.design components to manage layouts and UI.

Android

We used Github's Issues and Pull Requests effectively in our opinion. Our base branch was /android, we developed new features in our new branches like /android-gradeview-enhancement, and after completed developing a new feature, we opened pull request and our code reviewed by two peer most of the time and then merged. After completion of Milestone 2, we merged our /android branch to master.

We usually managed our group work by talking and dividing the work between each other. We talked about which part to be implemented and divide the part. Then we would together or on our own implement the part and send each other code reviews. We are happy about the communication between our own Android team but we need to improve our communication with other teams as well, because in some cases there exists incompatible practices arises in UI.

Back-End

As the Back-End team, we use Github's issue system and we create a new branch for each issue with the issue id since we want it to be unique. After the development and testing is done, we did pull request, did code review on Github, then merged the branch into the master.