Rules - SCAR-EAFIT/Documentations GitHub Wiki

GitHub Repository

Branchs

By default, each repository will have one branch:

  1. main/master: Represents the state in the production of the repository, the idea is to merge this branch from another development branch (fast-forward merges) when the student coordinators approve the changes (they are the reviewers).

Branch naming

If you are going to add something to this repository, you should create a new branch using the following rules:

  • feat/{feature-name}: For adding a new feature.
  • doc/{app-name}: For documenting.
  • fix/{feature/app-name}: Fixing a feature. Small code changes, and adds no new features.
  • ref/{feature/app-name}: When enhancing or restructuring documentation.
  • style/{feature/app-name}: For fixing coding style. E.g. remove end of line spaces or exchange tabs for spaces.

And always remember:

  • Do not directly modify the main branch.
  • Execute git pull before starting to work.

Commits

The structure of a commit should be:

  1. Title: (50 chars max)
  2. White line: Empty line between the title and the body message of the commit.
  3. Body: Explanation of the changes being merged. This can be an explanation of why is it necessary for the changes to be merged.

A template of the commit message:

Title

- Change 01
- Change 02
...
- Change n

It may seem redundant to list the changes, but it'll help the reviewer of the pull request (PR) to understand more easily what you did on the branch and at the same time help him to navigate the source code. Always remember:

  • Do not assume the reviewer understands what the original problem was.
  • Do not think your code is self-explanatory.

Also, we recommend you do small commits rather than big commits with a lot of changes. It would be easier to see the changes that you have made.

Create Pull Requests

After creating a new branch and adding changes you can upload your branch into GitHub and create a Pull Request.

Pull requests should be assigned to the student(s) coordinator(s) as reviewers, and be approved by one of them.

The message of the PR should be the compilation of the messages within the commits that the branch should contain.