Graham/angular-cli
1
0
Fork 0
mirror of https://github.com/angular/angular-cli.git synced 2025-05-15 18:13:38 +08:00
Code Issues Packages Projects Releases Wiki Activity

docs: update release doc with more merge details

Browse Source 
Added some additional details for how the caretaker should merge PRs, including a GitHub search which lists all pending PRs.
This commit is contained in:
Doug Parker 2019-11-20 09:19:57 -08:00 committed by Douglas Parker
parent e40be06703
commit 5c9fc32ae6
1 changed files with 30 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

35
docs/process/release.md
View File

@ -1,7 +1,3 @@
> Hans Larsen (hansl@google.com)
> June 8th, 2018
# Setting Up Local Repository
1. Clone the Angular-CLI repo. A local copy works just fine.
@ -20,12 +16,24 @@ Caretaker calendar can be found [here](https://calendar.google.com/calendar?cid=
TBD
## Merging PRs
TBD
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+review%3Aapproved+status%3Asuccess).
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
Everytime a PR is merged, commits need to be cherry-picked to an associated branch;
* the latest patch branch (e.g. `1.2.x` or `1.3.x-rc.0`) should also be updated by cherry-picking all _applicable_
commits to it. `fix()`, `docs()`, `refactor()` and
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;
@ -54,6 +62,7 @@ git checkout <patch branch>
# Cherry pick the commit. Use the hash from the commit which was merged
# into upstream/master, which should be known to your local repo.
git cherry-pick -x <commit hash from master>
# If you have multiple cherry picks, you can do them all here.
# Resolve merge conflicts if necessary...
# Or abort and ask author to submit a separate commit targeting patch-only.
@ -62,6 +71,16 @@ git cherry-pick -x <commit hash from master>
git push upstream <patch branch>
```
If you get a `bad revision` error when cherry picking, make sure you are using
the commit hash used when merged into `master`, _not_ the hash listed in the PR.
Also verify that you have fetched `master` from `upstream` since that commit was
merged.
If the commit is not merged to `master` (because it targets `patch only` for
instance), then you will need to fetch the contributor's branch for your local
Git instance to have knowledge of the commit being cherry picked onto the patch
branch.
# Release
## Before releasing