<commit_before># Setting Up Local Repository

1. Clone the Angular-CLI repo. A local copy works just fine.
1. Create an upstream remote:
  ```bash
  $ git remote add upstream https://github.com/angular/angular-cli.git
  ```

# Caretaker

The caretaker should triage issues, merge PR, and sheppard the release.

Caretaker calendar can be found [here](https://calendar.google.com/calendar/embed?src=angular.io_jf53juok1lhpm84hv6bo6fmgbc%40group.calendar.google.com&ctz=America%2FLos_Angeles).

Each shift consists of two caretakers. The primary caretaker is responsible for
merging PRs to master and patch whereas the secondary caretaker is responsible
for the release. Primary-secondary pairs are as follows:

Primary | Secondary
--------|----------
Alan    | Doug
Charles | Keen
Filipe  | Minko

## Triaging Issues
TBD

## Merging PRs

The list of PRs which are currently ready to merge (approved with passing status checks) can
be found with [this search](https://github.com/angular/angular-cli/pulls?q=is%3Apr+is%3Aopen+label%3A%22PR+action%3A+merge%22+-is%3Adraft).
This list should be checked daily and any ready PRs should be merged. For each
PR, check the `PR target` label to understand where it should be merged to. If
`master` is targetted, then click "Rebase and Merge". If the PR also targets a
patch branch, see [Maintaining Patch Branches](#maintaining-patch-branches).
Whatever the target, rebasing should be used over merging to avoid cluttering
the Git history with merge commits.

### Maintaining Patch Branches

When a PR is merged, if the `PR target` label includes a branch other than
`master`, commits will need to be cherry-picked to an associated branch. In
particular, the `patch` target simply refers to the latest patch branch (eg.
`1.2.x` or `1.3.x-rc.0`). This branch should be updated by cherry-picking all
_applicable_ commits to it, such as those with messages beginning with `fix()`,
`docs()`, or `refactor()`.

Say the following PR is merged;

```text
* fix(@angular/cli): fix path when doing stuff
* refactor(@angular-devkit/core): replace Fizz with Buzz
* feat(@angular-devkit/core): add new feature
* fix(@angular-devkit/core): fix something related to new feature
* refactor(@angular-devkit/core): move stuff to new feature
```

Only the first 2 commits should be cherry picked to the patch branch, as the last 3 are related to a new feature.

Cherry picking is done by checking out the patch branch and cherry picking the new commit onto it.
The patch branch is simply named as a version number, with a X in the relevant spot, such as `9.0.x`.
This should be done after merging to master.

```shell
# Make sure commit to upstream/master is present in local repo.
git fetch upstream master

# Check out patch branch from upstream.<commit_msg>docs: update release doc to remove outdate information on patch merges<commit_after># Setting Up Local Repository

1. Clone the Angular-CLI repo. A local copy works just fine.
1. Create an upstream remote:
  ```bash
  $ git remote add upstream https://github.com/angular/angular-cli.git
  ```

# Caretaker

The caretaker should triage issues, merge PR, and sheppard the release.

Caretaker calendar can be found [here](https://calendar.google.com/calendar/embed?src=angular.io_jf53juok1lhpm84hv6bo6fmgbc%40group.calendar.google.com&ctz=America%2FLos_Angeles).

Each shift consists of two caretakers. The primary caretaker is responsible for
merging PRs to master and patch whereas the secondary caretaker is responsible
for the release. Primary-secondary pairs are as follows:

Primary | Secondary
--------|----------
Alan    | Doug
Charles | Keen
Filipe  | Minko

## Triaging Issues
TBD

## Merging PRs

The list of PRs which are currently ready to merge (approved with passing status checks) can
be found with [this search](https://github.com/angular/angular-cli/pulls?q=is%3Apr+is%3Aopen+label%3A%22PR+action%3A+merge%22+-is%3Adraft).
This list should be checked daily and any ready PRs should be merged. For each
PR, check the `PR target` label to understand where it should be merged to. If
`master` is targetted, then click "Rebase and Merge". If the PR also targets a
patch branch, see [Maintaining Patch Branches](#maintaining-patch-branches).
Whatever the target, rebasing should be used over merging to avoid cluttering
the Git history with merge commits.

### Maintaining Patch Branches

When a PR is merged, if the `PR target` label includes a branch other than
`master`, commits will need to be cherry-picked to an associated branch. In
particular, the `patch` target simply refers to the latest patch branch (eg.
`1.2.x` or `1.3.x-rc.0`). This branch should be updated by cherry-picking all
commits from the PR to it.

Cherry picking is done by checking out the patch branch and cherry picking the new commit onto it.
The patch branch is simply named as a version number, with a X in the relevant spot, such as `9.0.x`.
This should be done after merging to master.

```shell
# Make sure commit to upstream/master is present in local repo.
git fetch upstream master

# Check out patch branch from upstream.
{'fraction_non_alphanumeric': 0.0825814044723421, 'fraction_numerical': 0.011377010592389172, 'mean_word_length': 4.418703506907545, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 6, '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': '1168934', 'n_tokens_mistral': 1525, 'n_tokens_neox': 1435, 'n_words': 686}