Repository Management Policy - SWE-574-Spring-2018/LinkyWay GitHub Wiki

Working with a team on a shared repository requires some ground rules considering the management of the repository. Following these set of rules will make it easy to work together and in harmony.

Commit Messages

Commit messages should consist of 3 parts, separated by underscore "_" and follow the conventions below:

  • First part should contain the corresponding task number. E.g BE-101, MB-102, UI-103.
  • Second part should contain the short item description. E.g Login Service Implementation.
  • Third part should contain the actual work done in a few words (no more than 8). E.g "login panel implementation has been completed".

Sample commit message: BE-101_Login Service Implementation_login panel implementation has been completed.

Working with branches

  • Each contributor will be working on the same repository. No additional fork is needed.
  • Master branch will be the only source for release and deployment.
  • Before starting implementation of a new feature or a bug fix, first a new remote branch should be created from the master branch in the main repository. Branch names should be short yet self-explanatory, and should start by an appropriate prefix value like feature or bugfix. E.g feature/login_service_implementation, bugfix/login_redirection_error.

Creating a pull request

  • Once you complete development of a certain task in your custom branch, it is time to push them to the upstream branch. Pull requests are used to notify repository owners about changes you've applied on your custom branch.
  • Master branch is the upstream branch in which all code changes should be gathered. No direct push is allowed to the master branch. Only way to update master branch is by creating pull requests.
  • By creating a pull request, you ask for permission to merge your changes in a custom branch to the master branch.
  • Following the PR creation, PR owner can ask repository owners for PR review (see pull request reviews).
  • Other contributors can review your proposed changes, add review comments, contribute to the pull request discussion, and even add commits to the pull request.
  • All pull requests should be reviewed and approved by at least 1 repository owner (excluding the PR owner).
  • Conflicts available in a pull request should be resolved by its owner.
  • Pull requests should pass all the integration tests before merging.
  • Once the reviews are completed and the PR is approved by a reviewer, it is ready to be merged to the master branch. Any contributor can complete the merge.