Skip to content

GITHUB and GIT Workflow

Jump to bottom
George Mcerlean edited this page May 24, 2020 · 7 revisions

Contribution to this project requires following the issue tracking and pull request conventions detailed within this document. Most important information regarding additions to the master branch can be found within the corresponding pull request and issues

Issues

There are two main types of issues

  • Feature requests - To add new features to the product or enhance existing features.
  • Bug reports - To report a bug to be fixed.

An issue for your changes should be present before you begin working on any code, with minor exceptions if the changes are small and you are communicating the changes with other developers. This is done to ensure there is no conflict in the work done by developers. Issues should be approved by at least one other developer.

Labels

Use the following labels on your issues/PRs to make them easily understandable

  • Approved - For issues that have passed review and can now be worked on
  • Backend - For issues/PRs which are related to the backend project
  • Bug - For issues regarding something which isn't working
  • Documentation - Improvements or additions to documentation
  • Duplicate - This issue or pull request already exists
  • Enhancement - New feature or request
  • Frontend - For frontend related issues
  • Help wanted - extra attention needed
  • invalid - Something is wrong with the issue or PR
  • Needs approval - For newly created issues that require review
  • Needs Review - For PRs which have been implemented and are awaiting review
  • UI - For issues purely about styling
  • wontfix - This will not be worked on

Git Workflow Step By Step Conventions:

  1. Update your local repository master with the most recent code from the main repository.
    git checkout master
    git pull
  1. Once you have an issue approved create a new branch on your local repository and push it to the remote repository
    git checkout master
    git checkout -b feature-descriptive-name
    git push --set-upstream origin feature-descriptive-name

  1. Make changes to the feature branch on your local branch, and commit/push regularly with descriptive messages - refer to Commit Messages below

  2. Test your changes either by writing unit tests or running the application and manually testing

  3. Merge the master branch into your local branch by doing the following:

    git checkout master
    git pull
    git checkout {name-of-work-branch}
    git merge master
  1. Push your local branch up to the repository by doing the following:
    git checkout {name-of-work-branch}
    git push

  1. Create the Pull Request:

    • On the Pull Requests tab of the main repository, open a pr for your branch into master
    • The pull request title should give developers an understanding of what has changed.
    • The body should provide more details about what changes have been made and should reference the number of the associated issue(s).
    • The title of the pull request should not just reference the issue number. Provide a short description of whats changed
    • Refer to the Pull Request template
    • One other group members must review and approve of the pull request.
    • Once the reviewer approves the pull request, they can merge your contribution into the main repository. Do not merge your own pull requests.

Pull Request Conventions

Aside from the instructions above, do not merge your own pull requests.

Branch Naming Conventions

Aside from branch prefixes (e.g. feature-...), please name the branches hyphen separated (-) and all lowercase.

Branch Prefixes

  • master - (Development branch) Usually integration branch for feature work and often defaults branch. For pull request workflows, the branch where new feature branches are targeted
  • feature- - (Feature branch) Used for specific feature work or improvements. Generally branches from, and merges back into, the development branch
  • fix- - (Bugfix branch) Typically used to fix development branch
  • Other prefixes - Other prefixes may be used as developers wish, however ensure they are appropriate (i.e. release for a release branch)

*Note: Typically use prefix branch feature-

Merging Branches

  • We squash branches onto development master development branch
    • This way we get 1 commit per pull request

Commit Messages

  • Make the commit messages concise, with no period at the end.
  • The main purpose of commit messages is to make it easy to navigate between commits.
  • If the issue you are referring to is fixed, is github notation to automatically close the issue
  • Do not try to explain changes just what has changed
Clone this wiki locally