6 GitHub
6.1 Commit messages
Commit messages can be very helpful to figure out what a commit does. Non-descriptive commit messages should be avoided. The following general guidelines should be considered when writing commit messages:
- The first line is the subject of the commit and should give a brief description
- If you need to include more detail skip a line then include more content
- If you are fixing issues you can add Fix #
as this will close the issue on GitHub when the commit is merged into the main branch.
6.2 Pull Requests
The title of the pull request should provide a brief description of what the pull request does.
If the PR fixes an issue include the phrase Fixes #
6.3 Branch names
Having descriptive branch names can be very useful in team development. Consistently naming branches can help with transparency and ease of tracking what branches are used for. Typically, branches are created to address issues such as new features, bug fixes or documentation for a particular branch like, Development, Dev-V0.1.2, master. Using the following labels Feature, Bugfix, Doc (for documentation) a branch name should be made like the following:
< label >-< Key word(s) >-< Developer Initials >
For example, if you are working a branch named Dev and you want to create a feature branch with a brief description of perform analysis and your initials are KW then a good branch name would be
Feature-Add-Analysis-KW
and if you wanted to reference an issue #14 then you could also include the issue number in the branch, for example
Feature14-Add-Analysis-KW.
A common practice is to create a Dev branch, set Dev as the default branch and require code reviews and Pull Requests for merges to the main or Dev branches. Typically feature branches are created off of the Dev branch then PRs will merge feature branches into Dev. After a release version is completed then Dev is merged into the main branch via a PR.