The following approach is to ensure a clean main branch and robust collaboration.
We will never work on the main branch because the main branch should only have stable, tested code. We would use a branch named dev in the UBC-MDS to which we raise PRs from our forked repos.
We use feature/feature_name ex: feature/data_download_script in our forked repos to implement new features for our project.
Once we are done with a feature we raise a PR from the feature/feature_name branch in the forked repo to the dev branch in the UBC-MDS repo. Reviewers will merge that with the dev branch if the changes look good, otherwise add comments to revise them.
Once the dev branch in the UBC-MDS repo is clean and stable with all the features for a particular milestone, we merge it with the main branch.
Important: Pull changes from the dev branch of the UBC-MDS repo to our local forked repo after a member has added a feature before starting a new feature. Then, create a feature branch named feature/feature_name based on the dev branch.
The following approach is to ensure a clean main branch and robust collaboration.
main
branch because the main branch should only have stable, tested code. We would use a branch nameddev
in the UBC-MDS to which we raise PRs from our forked repos.feature/feature_name
ex:feature/data_download_script
in our forked repos to implement new features for our project.feature/feature_name
branch in the forked repo to thedev
branch in the UBC-MDS repo. Reviewers will merge that with thedev
branch if the changes look good, otherwise add comments to revise them.dev
branch in the UBC-MDS repo is clean and stable with all the features for a particular milestone, we merge it with themain
branch.dev
branch of the UBC-MDS repo to our local forked repo after a member has added a feature before starting a new feature. Then, create a feature branch namedfeature/feature_name
based on thedev
branch.