Git Workflow - TorinitTechnologies/Torinit-Coding-Guidelines GitHub Wiki

Feature Branching Strategy

To protect the integrity of the codebase, we will follow a feature branching strategy as the main git workflow.

For a complete explanation of this strategy, please review this tutorial. Key points are summarized below.

Summary

  • The master branch should be the main branch.

  • The local master should be updated to match the remote master branch.

$ git checkout master
$ git fetch origin
$ git reset --hard origin/master
  • A new branch should be created locally from master to begin work on a new feature. The branch should be named after the feature (e.g. user-profile-page), the issue # (e.g. issue-106), or bug description (e.g. authentication-eror).
$ git checkout -b new-feature

  • Make all commits locally to the feature branch.

  • Push the feature branch to the remote repository.

$ git push -u origin new-feature

  • Continue to commit and push changes until the feature is complete or the issue is resolved.

  • Submit a pull request. Comment on the pull request and request any help, if necessary.

  • Another developer should review the pull request. Any developer can comment and discuss the code and any changes or amendments that should be made.

  • Code must comply with the style guide, and this should be considered when reviewing a feature branch.

  • Changes and any merge conflicts should be resolved locally, then pushed to the feature branch.

  • When the feature development is complete and without merge conflicts or style issues, the pull request should be merged via Github by a different developer than the one who wrote the code in the branch.

  • Feature branches should not be merged locally before pushing. They should always be pushed and then merged to master via pull request.

  • Ensure that code is linted and correctly formatted before pushing and before merging.