|
29 | 29 |
|
30 | 30 | The list of PRs which are currently ready to merge (approved with passing status checks) can
|
31 | 31 | 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).
|
32 |
| -This list should be checked daily and any ready PRs should be merged. For each |
33 |
| -PR, check the `PR target` label to understand where it should be merged to. If |
34 |
| -`master` is targetted, then click "Rebase and Merge". If the PR also targets a |
35 |
| -patch branch, see [Maintaining Patch Branches](#maintaining-patch-branches). |
36 |
| -Whatever the target, rebasing should be used over merging to avoid cluttering |
37 |
| -the Git history with merge commits. |
38 |
| - |
39 |
| -### Maintaining Patch Branches |
40 |
| - |
41 |
| -When a PR is merged, if the `PR target` label includes a branch other than |
42 |
| -`master`, commits will need to be cherry-picked to an associated branch. In |
43 |
| -particular, the `patch` target simply refers to the latest patch branch (eg. |
44 |
| -`1.2.x` or `1.3.x-rc.0`). This branch should be updated by cherry-picking all |
45 |
| -commits from the PR to it. |
46 |
| - |
47 |
| -Cherry picking is done by checking out the patch branch and cherry picking the new commit onto it. |
48 |
| -The patch branch is simply named as a version number, with a X in the relevant spot, such as `9.0.x`. |
49 |
| -This should be done after merging to master. |
50 |
| - |
51 |
| -```shell |
52 |
| -# Make sure commit to upstream/master is present in local repo. |
53 |
| -git fetch upstream master |
54 |
| - |
55 |
| -# Check out patch branch from upstream. |
56 |
| -git fetch upstream <patch branch> |
57 |
| -git checkout <patch branch> |
58 |
| - |
59 |
| -# Cherry pick the commit. Use the hash from the commit which was merged |
60 |
| -# into upstream/master, which should be known to your local repo. |
61 |
| -git cherry-pick -x <commit hash from master> |
62 |
| -# If you have multiple cherry picks, you can do them all here. |
63 |
| - |
64 |
| -# Resolve merge conflicts if necessary... |
65 |
| -# Or abort and ask author to submit a separate commit targeting patch-only. |
66 |
| - |
67 |
| -# Push changes. |
68 |
| -git push upstream <patch branch> |
69 |
| -``` |
| 32 | +This list should be checked daily and any ready PRs should be merged. For each PR, check the |
| 33 | +`PR target` label to understand where it should be merged to. You can find which branches a specific |
| 34 | +PR will be merged into with the `yarn ng-dev pr check-target-branches <pr>` command. |
70 | 35 |
|
71 |
| -If you get a `bad revision` error when cherry picking, make sure you are using |
72 |
| -the commit hash used when merged into `master`, _not_ the hash listed in the PR. |
73 |
| -Also verify that you have fetched `master` from `upstream` since that commit was |
74 |
| -merged. |
| 36 | +When ready to merge a PR, run the following command: |
| 37 | +``` |
| 38 | +yarn ng-dev pr merge <pr> |
| 39 | +``` |
75 | 40 |
|
76 |
| -If the commit is not merged to `master` (because it targets `patch only` for |
77 |
| -instance), then you will need to fetch the contributor's branch for your local |
78 |
| -Git instance to have knowledge of the commit being cherry picked onto the patch |
79 |
| -branch. |
80 | 41 |
|
81 | 42 | ### Maintaining LTS branches
|
82 | 43 |
|
|
0 commit comments