@ou-imdt/create/CONTRIBUTING.md

Command line tool to create team boilerplate.

# Contribution guidelines

Thank you for considering contributing to CREATE! This document provides the guidelines required for contributing effectively.

## Getting started

1. Clone the repository:

```sh
git clone git@bitbucket.org:lts-imd/create.git
```

2. Install dependencies:

```sh 
npm install
```
## Working with branches

### Update your local `dev` branch:

Ensure your local `dev` branch is up-to-date with the remote `dev` branch.

```sh
git checkout dev
git pull
```

### Create a new branch off `dev`:

Use the format of `feature/[name]-dev`

### Development practices:

- Use `feature/` for new developments (to dev).
- Use `bugfix/` for bug fixes (to dev).
- Use `release/` for releases (to main).
- Use `hotfix/` for hotfixes (to main).
- Always prefer `git pull --rebase` to avoid unnecessary merge commits.
```sh
git pull --rebase origin dev
```
- If any conflicts during the rebase resolve them. If you want to abort the rebase for a reason:
```sh
git rebase --abort
```

#### Notes to release managers

Use below branching conventions for release/hotfix:

- Branch prefix: `release/`

- Branch prefix: `hotfix/`

### Commit messages

Use following format for commit messages:
- feat: A new feature
- fix: A bug fix
- docs: Documentation only changes
- style: white-space, formatting that doesn't affect code meaning
- refactor: A code change that neither fixes a bug nor adds a feature
- test: Adding/updating tests
- chore: Changes to the build process, tools, scripts 

### Making changes

1. Push changes:
   
Once you have completed your changes, push them to your branch.
```bash
git push origin <branch-name>
```
2. Create a pull request:

 Initiate a pull request from your branch to the `dev` branch for review.

### Review and merging

#### Code Review:

All changes will be reviewed by assigned reviewers before merging.

#### After Merging:

Once your changes have been merged, mark the JIRA issue (if any) as resolved.


## Local testing:

Run `npm link` in the CREATE root directory to test the locally installed package.

Run `npm unlink create` to remove the local package.

`--debug/-d` flag is available to see the debug logs.

## Pre-publish tasks:

- Bump the version number in `package.json` and update `changelog.md`.

- npm publish dry run: `npm publish --dry-run` to get a preview of the files that will be published.

- Git commit and push the changes.

- Send a PR to `main`, the Bitbucket pipeline will run and publish the new version. 

>Below steps are for manual publish you don't need them but keeping here if we ever need to do it again.

- Check if logged in to npm: `npm whoami`. If not logged in, login to npm: `npm login`

- Publish the package: `npm publish --access public` 🚀

> When publishing a beta version use `npm publish --tag beta` then there are two options for install, this way beta version won't be available via latest and won't auto install on `npm update` or ncu :
  - npm install @ou-imdt/create@beta
  - npm install @ou-imdt/create@2.0.0-beta.1