Code Structure and Group Process - bounswe/bounswe2019group9 GitHub Wiki

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.

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 one peer most of the time and then merged. After completion of Milestone 1, 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 some more communication with other teams and work on it.

Back-End

In back-end team, we don't have any main branch for development. 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 basicly merge the branch into master.