<commit_before># Pull Requests

* [Setting up your local environment](#setting-up-your-local-environment)
  * [Step 1: Fork](#step-1-fork)
  * [Step 2: Build](#step-2-build)
  * [Step 3: Branch](#step-3-branch)
* [Making Changes](#making-changes)
  * [Step 4: Code](#step-4-code)
    * [How to add card](#how-to-add-card)
    * [How to add task](#how-to-add-task)
  * [Step 5: Commit](#step-5-commit)
    * [Commit message guidelines](#commit-message-guidelines)
  * [Step 6: Rebase](#step-6-rebase)
  * [Step 7: Test](#step-7-test)
    * [How to add test](#how-to-add-test)
  * [Step 8: Push](#step-8-push)
  * [Step 9: Opening the Pull Request](#step-9-opening-the-pull-request)
  * [Step 10: Discuss and Update](#step-10-discuss-and-update)
    * [Approval and Request Changes Workflow](#approval-and-request-changes-workflow)
  * [Step 11: Landing](#step-11-landing)
  * [Continuous Integration Testing](#continuous-integration-testing)
  * [Code Coverage Testing](#code-coverage-testing) 
  * [Code Quality Checking](#code-quality-checking)

## Setting up your local environment

### Step 1: Fork

Fork the project [on GitHub](https://github.com/utilForever/Hearthstone++) and clone your fork
locally.

```
$ git clone <EMAIL>@github.com:username/Hearthstonepp.git
$ cd Hearthstonepp
$ git remote add upstream https://github.com/utilForever/Hearthstonepp.git
$ git fetch upstream
```

### Step 2: Build

Build steps and dependencies differ slightly depending on your operating system.
See these detailed guides on building Hearthstone++ locally:
* [Building on MacOS](https://github.com/utilForever/Hearthstonepp/blob/documentation/INSTALL.md#building-from-macos)
* [Building on Ubuntu or WSL(Windows Subsystem for Linux)](https://github.com/utilForever/Hearthstonepp/blob/documentation/INSTALL.md#building-from-ubuntu-and-windows-subsystem-for-linux-wsl)
* [Building on Windows](https://github.com/utilForever/Hearthstonepp/blob/documentation/INSTALL.md#building-from-windows)

Once you've built the project locally, you're ready to start making changes!

### Step 3: Branch

To keep your development environment organized, create local branches to
hold your work. These should be branched directly off of the `master` branch.

```
$ git checkout -b my-branch -t upstream/master
```

## Making Changes

### Step 4: Code

Most pull requests opened against the `utilForever/Hearthstonepp` repository include
changes to either the core C/C++ code in the `Includes/` or `Sources/` folders,
3rd-party libraries in the `Libraries/` folder, console or GUI program in the `Programs/` folder,
the documentation in `Documents/` or tests in the `Tests/` folder.

***NOTE: Please be sure to apply `.clang-format` from time to time on any code changes
to ensure that they follow the project's code style.***

#### How to add card

See [HOW_TO_ADD_CARD.md](https://github.com/utilForever/Hearthstonepp/blob/master/HOW_TO_ADD_CARD.md) for more details.

#### How to add task

See [HOW_TO_ADD_TASK.md](https://github.com/utilForever/Hearthstonepp/blob/master/HOW_TO_ADD_TASK.md) for more details.

### Step 5: Commit

It is recommended to keep your changes grouped logically within individual
commits. Many contributors find it easier to review changes that are split
across multiple commits. There is no limit to the number of commits in a
pull request.

```
$ git add my/changed/files
$ git commit
```

Note that multiple commits often get squashed when they are landed.

#### Commit message guidelines

A good commit message should describe what changed and why. Hearthstone++ project
uses [semantic commit messages](https://conventionalcommits.org/) to streamline
the release process.

Before a pull request can be merged, it **must** have a pull request title with a semantic prefix.

Examples of commit messages with semantic prefixes:

- `feat: allow provided config object to extend other configs`
- `docs: correct spelling of CHANGELOG`
- `feat(lang): add polish language`
- `fix: correct minor typos in code`

Common prefixes:

  - fix: A bug fix
  - feat: A new feature
  - docs: Documentation changes
  - test: Adding missing tests or correcting existing tests
  - build: Changes that affect the build system
  - ci: Changes to our CI configuration files and scripts
  - perf: A code change that improves performance
  - refactor: A code change that neither fixes a bug nor adds a feature
  - style: Changes that do not affect the meaning of the code (linting)

Other things to keep in mind when writing a commit message:

1. The first line should:
   - contain a short description of the change (preferably 50 characters or less,
     and no more than 72 characters)
   - be entirely in lowercase with the exception of proper nouns, acronyms, and
   the words that refer to code, like function/variable names
2. Keep the second line blank.
3. Wrap all other lines at 72 columns.

#### Breaking Changes

A commit that has the text `BREAKING CHANGE:` at the beginning of its optional
body or footer section introduces a breaking API change (correlating with Major
in semantic versioning). A breaking change can be part of commits of any type.
e.g., a `fix:` & `feat:` types would all be valid, in addition to any
other type.

See [conventionalcommits.org](https://conventionalcommits.org) for more details.

### Step 6: Rebase

Once you have committed your changes, it is a good idea to use `git rebase`
(not `git merge`) to synchronize your work with the main repository.

```
$ git fetch upstream
$ git rebase upstream/master
```

This ensures that your working branch has the latest changes from `utilForever/Hearthstonepp`
master.

### Step 7: Test

Bug fixes and features should always come with tests. A
[testing guide](https://github.com/utilForever/Hearthstonepp/blob/documentation/TESTING.md) has been
provided to make the process easier. Looking at other tests to see how they
should be structured can also help.

Before submitting your changes in a pull request, always run the full
test suite. To run the tests:

```
bin/UnitTests
```

Make sure the linter does not report any issues and that all tests pass.
Please do not submit patches that fail either check.

#### How to add test

See [HOW_TO_ADD_TEST.md](https://github.com/utilForever/Hearthstonepp/blob/master/HOW_TO_ADD_TEST.md) for more details.

### Step 8: Push

Once your commits are ready to go -- with passing tests and linting --
begin the process of opening a pull request by pushing your working branch
to your fork on GitHub.
<commit_msg>[ci skip] docs: Delete contents<commit_after># Pull Requests

* [Setting up your local environment](#setting-up-your-local-environment)
  * [Step 1: Fork](#step-1-fork)
  * [Step 2: Build](#step-2-build)
  * [Step 3: Branch](#step-3-branch)
* [Making Changes](#making-changes)
  * [Step 4: Code](#step-4-code)
    * [How to add card](#how-to-add-card)
    * [How to add task](#how-to-add-task)
  * [Step 5: Commit](#step-5-commit)
    * [Commit message guidelines](#commit-message-guidelines)
  * [Step 6: Rebase](#step-6-rebase)
  * [Step 7: Test](#step-7-test)
  * [Step 8: Push](#step-8-push)
  * [Step 9: Opening the Pull Request](#step-9-opening-the-pull-request)
  * [Step 10: Discuss and Update](#step-10-discuss-and-update)
    * [Approval and Request Changes Workflow](#approval-and-request-changes-workflow)
  * [Step 11: Landing](#step-11-landing)
  * [Continuous Integration Testing](#continuous-integration-testing)
  * [Code Coverage Testing](#code-coverage-testing) 
  * [Code Quality Checking](#code-quality-checking)

## Setting up your local environment

### Step 1: Fork

Fork the project [on GitHub](https://github.com/utilForever/Hearthstone++) and clone your fork
locally.

```
$ git clone <EMAIL>:username/Hearthstonepp.git
$ cd Hearthstonepp
$ git remote add upstream https://github.com/utilForever/Hearthstonepp.git
$ git fetch upstream
```

### Step 2: Build

Build steps and dependencies differ slightly depending on your operating system.
See these detailed guides on building Hearthstone++ locally:
* [Building on MacOS](https://github.com/utilForever/Hearthstonepp/blob/documentation/INSTALL.md#building-from-macos)
* [Building on Ubuntu or WSL(Windows Subsystem for Linux)](https://github.com/utilForever/Hearthstonepp/blob/documentation/INSTALL.md#building-from-ubuntu-and-windows-subsystem-for-linux-wsl)
* [Building on Windows](https://github.com/utilForever/Hearthstonepp/blob/documentation/INSTALL.md#building-from-windows)

Once you've built the project locally, you're ready to start making changes!

### Step 3: Branch

To keep your development environment organized, create local branches to
hold your work. These should be branched directly off of the `master` branch.

```
$ git checkout -b my-branch -t upstream/master
```

## Making Changes

### Step 4: Code

Most pull requests opened against the `utilForever/Hearthstonepp` repository include
changes to either the core C/C++ code in the `Includes/` or `Sources/` folders,
3rd-party libraries in the `Libraries/` folder, console or GUI program in the `Programs/` folder,
the documentation in `Documents/` or tests in the `Tests/` folder.

***NOTE: Please be sure to apply `.clang-format` from time to time on any code changes
to ensure that they follow the project's code style.***

#### How to add card

See [HOW_TO_ADD_CARD.md](https://github.com/utilForever/Hearthstonepp/blob/master/HOW_TO_ADD_CARD.md) for more details.

#### How to add task

See [HOW_TO_ADD_TASK.md](https://github.com/utilForever/Hearthstonepp/blob/master/HOW_TO_ADD_TASK.md) for more details.

### Step 5: Commit

It is recommended to keep your changes grouped logically within individual
commits. Many contributors find it easier to review changes that are split
across multiple commits. There is no limit to the number of commits in a
pull request.

```
$ git add my/changed/files
$ git commit
```

Note that multiple commits often get squashed when they are landed.

#### Commit message guidelines

A good commit message should describe what changed and why. Hearthstone++ project
uses [semantic commit messages](https://conventionalcommits.org/) to streamline
the release process.

Before a pull request can be merged, it **must** have a pull request title with a semantic prefix.

Examples of commit messages with semantic prefixes:

- `feat: allow provided config object to extend other configs`
- `docs: correct spelling of CHANGELOG`
- `feat(lang): add polish language`
- `fix: correct minor typos in code`

Common prefixes:

  - fix: A bug fix
  - feat: A new feature
  - docs: Documentation changes
  - test: Adding missing tests or correcting existing tests
  - build: Changes that affect the build system
  - ci: Changes to our CI configuration files and scripts
  - perf: A code change that improves performance
  - refactor: A code change that neither fixes a bug nor adds a feature
  - style: Changes that do not affect the meaning of the code (linting)

Other things to keep in mind when writing a commit message:

1. The first line should:
   - contain a short description of the change (preferably 50 characters or less,
     and no more than 72 characters)
   - be entirely in lowercase with the exception of proper nouns, acronyms, and
   the words that refer to code, like function/variable names
2. Keep the second line blank.
3. Wrap all other lines at 72 columns.

#### Breaking Changes

A commit that has the text `BREAKING CHANGE:` at the beginning of its optional
body or footer section introduces a breaking API change (correlating with Major
in semantic versioning). A breaking change can be part of commits of any type.
e.g., a `fix:` & `feat:` types would all be valid, in addition to any
other type.

See [conventionalcommits.org](https://conventionalcommits.org) for more details.

### Step 6: Rebase

Once you have committed your changes, it is a good idea to use `git rebase`
(not `git merge`) to synchronize your work with the main repository.

```
$ git fetch upstream
$ git rebase upstream/master
```

This ensures that your working branch has the latest changes from `utilForever/Hearthstonepp`
master.

### Step 7: Test

Bug fixes and features should always come with tests. A
[testing guide](https://github.com/utilForever/Hearthstonepp/blob/documentation/TESTING.md) has been
provided to make the process easier. Looking at other tests to see how they
should be structured can also help.

Before submitting your changes in a pull request, always run the full
test suite. To run the tests:

```
bin/UnitTests
```

Make sure the linter does not report any issues and that all tests pass.
Please do not submit patches that fail either check.

### Step 8: Push

Once your commits are ready to go -- with passing tests and linting --
begin the process of opening a pull request by pushing your working branch
to your fork on GitHub.

{'fraction_non_alphanumeric': 0.09673405909797823, 'fraction_numerical': 0.006842923794712286, 'mean_word_length': 4.3609837432263445, 'pattern_counts': {'":': 0, '<': 5, '<?xml version=': 0, '>': 5, 'https://': 21, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '180680', 'n_tokens_mistral': 3950, 'n_tokens_neox': 3638, 'n_words': 1553}