4
1
Fork 0
2 Gitea, and general Git usage
Sudharshan S edited this page 2019-07-28 06:52:10 +00:00

Introduction

This wiki page contains the SOP relating to the usage of Git version control, branches, semantic commits, protected master and other requirements and procedures when developers are working on any of the Beep repositories. Each of these points are covered in more extensive detail in the following sections.

Resources for learning Git

For new users of Git, the following links would be of use to get you up and running on the basics.

Semantic commits & pull requests

At Beep, we use semantic commits to create a changelog within our commits. This requires that each commit follow a specific format, not just for readability but also to track changes in the repo and to differentiate between the different tasks one might be providing. The semantic commit standard is as follows.

feat: add hat wobble
^--^  ^------------^
|     |
|     +-> Summary in present tense.
|
+-------> Type: chore, docs, feat, fix, refactor, style, or test.

Each commit message is started with a type, which describes the type of change being committed to the repo. Then this is followed by a summary of the commit in present tense.

Pull requests follow the same naming style as commits.

Protected branches and how to use them

The master/staging branches of each repo are protected branches by default. Thus, no user has direct push access to these branches. The correct way to push changes to staging would be to use git branching and create a seperate branch for your git issue/feature. Then, create a pull request within the branch to merge the branch into master/staging.

With a minimum review count of 1, another individual must go through your code and approve it before being allowed to merge into master. After this process is complete, merge in the branch and delete the branch to avoid any dangling branches.

Branch semantic naming

Much like commits, branches also have a semantic naming standard. This serves a similar purpose to commits, helping to easily keep track of pull requests and the features they enable. The semantic branch naming standard is as follows.

feat\add-hat-wobble
^--^ ^---------------^
|    |
|    +-> Summary in present tense.
|
+------> Type: chore, docs, feat, fix, refactor, style, or text.