管理Pull Request（PR）是软件开发协作中的一个关键过程，特别是在使用Git进行版本控制时

管理Pull Request（PR）是软件开发协作中的一个关键过程，特别是在使用Git进行版本控制时。下面是对如何管理Pull Request的详细解析：

1. 创建Pull Request

步骤解析：

• Fork仓库：

  • 在GitHub、GitLab或Bitbucket等平台上，fork你想要贡献的仓库。这会在你的账户下创建一个仓库的副本。

• 克隆Fork的仓库：

  • 将fork的仓库克隆到你的本地机器上，使用命令：

    git clone <你的fork仓库的URL>
    

• 创建新分支：

  • 为你的更改创建一个新的分支。使用描述性的名称来命名分支：

    git checkout -b <新分支名称>
    

• 进行更改：

  • 在新分支上对代码进行必要的更改。

• 提交更改：

  • 将更改的文件添加到暂存区，并提交它们，附带清晰的提交信息：

    git add .
    git commit -m "描述性的提交信息"
    

• 推送分支：

  • 将你的新分支推送到你在平台上的远程fork：

    git push origin <新分支名称>
    

• 创建Pull Request：

  • 在平台的网站上，导航到你的fork。你应该会看到一个“New Pull Request”或“Compare & Pull Request”的按钮。
  • 选择你的分支作为源，原始仓库的主分支（如main、master）作为目标。
  • 填写PR的标题和描述，解释你做了哪些更改以及为什么。
  • 点击“Create Pull Request”或“Open Pull Request”。

2. 审查Pull Request

步骤解析：

• 查看Pull Request：

  • 在平台的网站上，导航到Pull Request。

• 审查更改：

  • 使用平台的差异查看器查看PR中的更改。
  • 你可以在代码行上直接添加评论，提供反馈或提问。

• 运行测试：

  • 如果仓库有自动化测试，确保PR通过了这些测试。
  • 你可以点击PR页面上的相应按钮来触发测试。

• 批准或请求更改：

  • 如果更改可以接受，你可以批准PR。
  • 如果需要更改，留下评论请求必要的更新。

3. 合并Pull Request

步骤解析：

• 确保所有检查通过：

  • 在合并之前，确保所有自动化检查（测试、代码质量检查等）都已通过。

• 解决冲突（如果有）：

  • 如果存在合并冲突，PR的创建者需要在他们的分支中解决这些冲突，并推送更新。

• 合并Pull Request：

  • 在平台的网站上，点击“Merge”按钮。
  • 选择合并方法（如squash and merge、rebase and merge、create a merge commit）。

• 删除分支：

  • 可选地，从远程仓库中删除分支以保持整洁。

4. 关闭Pull Request

步骤解析：

• 不合并关闭：

  • 如果PR不适合合并，点击“Close”按钮。
  • 可选地，留下评论解释为什么关闭PR。

• 合并后关闭：

  • 合并PR后，平台通常会自动关闭它。

5. 管理Pull Request的最佳实践

• 清晰的提交信息：

  • 编写描述性且简洁的提交信息，解释每个提交的目的。

• 定期审查：

  • 定期审查PR，以确保及时提供反馈和集成更改。

• 自动化测试：

  • 确保仓库有自动化测试来验证PR。

• 代码质量工具：

  • 使用代码质量工具和linter来强制执行编码标准。

• 文档：

  • 随着代码更改一起更新任何相关的文档。

• 沟通：

  • 保持沟通开放和友好。鼓励在PR中提问和讨论。

通过遵循这些步骤和最佳实践，你可以有效地管理Pull Request，确保代码更改得到审查、测试和顺利集成到主分支中。
This page guides you through Git setup and contribution process.
On This Page

Git setup for Contributors
Do some work on the branch
How to create a PR (committers)
How to create a PR (contributors)
Check List for a PR
Merging a PR (yours or contributors)
Closing a PR without committing (for committers)

Git setup for Contributors

First of all, fork github’s apache/rocketmq to your own account on github and clone it as follows,

git clone https://github.com/<your_github_name>/rocketmq.git

Cloning this locally will set up origin to point to your remote fork on github as the default remote. Now you can create your pull requests.

You will need to update a local master sometimes (to merge to your development branches). For this, you have to add remote for RocketMQ mirror as follows,

git remote add apache https://github.com/apache/rocketmq.git

and update your local master via git fetch followed by git rebase, for instance:

git fetch apache master
git rebase apache/master

Do some work on the branch

git commit -a -m “doing some work”
git push origin ROCKETMQ-xxxx # notice pushing to origin not apache

Once you are ready to commit to the apache remote you can merge and push them directly, otherwise always create a PR.
How to create a PR (committers)

Push your branch to Github:

git checkout ROCKETMQ-xxxx
git push origin ROCKETMQ-xxxx

Go to your ROCKETMQ-xxxx branch on Github. Since you forked it from Github’s apache/rocketmq. By default all PR will go to apache/master.
Click the green “Compare, review, and create pull request” button. You can edit the to and from for the PR if it isn’t correct. The “base fork” should be apache/rocketmq unless you are collaborating with one of the committers on the list. The “base” will be master. Don’t submit a PR to any other branches unless permitted by branch owner. The “head fork” will be your forked repo and the “compare” will be your ROCKETMQ-xxxx branch.
Click the “Create pull request” button and name the request “ROCKETMQ-xxxx” all caps. This will connect the comments of the PR to the mailing list and issue comments.
From now on the PR lives on github’s apache/rocketmq. You can use the commenting UI there.
If you are looking for a review or wanting to share with someone else please write a note in the comments and don’t worry about automated merging of your PR – you will have to do that later. The PR is tied to your branch so you can respond to comments, make fixes, and commit them from your local repo. They will appear on the PR page and be mirrored to Github issue and the mailing list.
When you are satisfied and want to push it to Apache’s remote repo, you can merge this PR.

How to create a PR (contributors)

Before you create a pull request, make sure

A corresponding Github issue is created and has a clear problem description.
Make sure you follow Coding Guidelines.
You have unit tests for everything you are about to commit.

For information about creating pull requests, please check GitHub PR docs.

Pull requests are made to apache/rocketmq repository on Github. In the Github UI you should pick the develop branch as target of the PR.
You pull request will be reviewed and commented by committers, and issues can be discussed. When all reviewers are positive on the pull request, it will be merged.
Check List for a PR

Each pull request should follow the checklist to help us incorporate your contribution quickly and easily.

Remember use - [x] mark an item finished in the check list and there is a demo pull request can be your reference.
Merging a PR (yours or contributors)

Start with reading GitHub PR merging locally. Remember that pull requests are equivalent to a remote github branch with potentially a multitude of commits. In this case it is recommended to squash remote commit history to have one commit per issue, rather than merging in a multitude of contributor’s commits. In order to do that, as well as to close the PR at the same time, it is recommended to use squash commits. Merging pull requests are equivalent to a “pull” of a contributor’s branch:

git checkout master # switch to local master branch
git pull apache master # fast-forward to current remote HEAD
git pull --squash https://github.com/cuser/rocketmq.git ROCKETMQ-xxxx # merge to master

–squash ensures all PR history is squashed into single commit, and allows committer to use his/her own message. Please refer to git help for merge or pull for more information about --squash option. In this example we assume that the contributor’s Github handle is “cuser” and the PR branch name is “ROCKETMQ-xxxx”. Next, resolve all conflicts, or ask a contributor to rebase on top of master, if PR went out of sync.

If you are ready to merge your own (committer’s) PR you only need to merge (not pull), since you have a local copy that you’ve been working on. This is the branch that you used to create the PR.

git checkout master # switch to local master branch
git pull apache master # fast-forward to current remote HEAD
git merge --squash ROCKETMQ-xxxx

Please run regular patch checks, build with tests enabled, and change CHANGELOG whenever needed. If all requirements are met, you can commit the squashed request using:

git commit --author=“contributor_name <contributor_email>” -a -m “ROCKETMQ-XXXX description closes apache/rocketmq#ZZ”

ROCKETMQ-XXXX is all capitalized and ZZ is the pull request number on apache/rocketmq repository. Including “closes apache/rocketmq#ZZ” will close the PR automatically. More information can be found here GitHub PR closing docs… Next, push to apache:

git push apache master

(this will require Apache handle credentials). The PR, once pushed, will get mirrored to github. To update your github version push there too:

git push origin master

Note on squashing: Since squash discards remote branch history, repeated PRs from the same remote branch are difficult to be merged. The workflow implies that every new PR starts with a new rebased branch. This is more important for contributors to know, rather than for committers, because if new PR is not mergeable, github would warn at the start. Please watch for dupe PRs (based on same source branches).
Closing a PR without committing (for committers)

When we want to reject a PR (close without committing), we can just issue an empty commit on master’s HEAD without merging the PR:

git commit --allow-empty -m “ROCKETMQ-XXXX closes apache/rocketmq#ZZ Won’t fix”
git push apache master

that should close PR ZZ on github mirror without merging and any code modifications in the master repository.

Updated: December 25, 2016
Share on
Twitter Facebook Google+ LinkedIn
Previous
Next
Leave a Comment
Apache Software Foundation

Follow: Twitter GitHub Feed 

Copyright © 2020 The Apache Software Foundation. Licensed under the Apache License, Version 2.0.
Apache RocketMQ, RocketMQ, Apache, the Apache feather logo and the Apache RocketMQ logo are trademarks of The Apache Software Foundation.

Apache RocketMQ
Documentation
Blog
Community
Users
About

User Guide
    Why RocketMQ
    Quick Start
    Simple Example
    Order Example
    Broadcasting Example
    Schedule Example
    Batch Example
    Filter Example
    Logappender Example
    OpenMessaging Example
    Transaction Example
    FAQ
Release Notes
    Download
Deployment & Operations
    Architecture
    Deployment
    CLI Admin Tool
Contributor Guide
    How To Contribute
    Code Guidelines
    Manage Pull Request
    Release Manual
Best Practice
    Core Concept
    Broker
    Producer
    Consumer
    NameServer
    JVM/Kernel Config

How to manage Pull Request

Managing Pull Requests (PRs) in Git involves several steps, from creating a PR to merging it into the main branch. Here’s a comprehensive guide on how to manage Pull Requests:

1. Creating a Pull Request

Steps:

1. Fork the Repository:

   • On platforms like GitHub, GitLab, or Bitbucket, fork the repository you want to contribute to. This creates a copy of the repository under your own account.

2. Clone the Forked Repository:

   • Clone the forked repository to your local machine using the command:

     git clone <URL-of-your-forked-repository>
     

3. Create a New Branch:

   • Create a new branch for your changes. Use a descriptive name for the branch:

     git checkout -b <new-branch-name>
     

4. Make Changes:

   • Make the necessary changes to the code on the new branch.

5. Commit Your Changes:

   • Add the changed files to the staging area and commit them with a clear message:

     git add .
     git commit -m "Descriptive commit message"
     

6. Push Your Branch:

   • Push your new branch to your remote fork on the platform:

     git push origin <new-branch-name>
     

7. Create a Pull Request:

   • On the platform’s website, navigate to your fork. You should see a button like “New Pull Request” or “Compare & Pull Request”.
   • Select your branch as the source and the main branch (e.g., main, master) of the original repository as the destination.
   • Fill in the title and description of the PR, explaining what changes you’ve made and why.
   • Click “Create Pull Request” or “Open Pull Request”.

2. Reviewing a Pull Request

Steps:

1. View the Pull Request:

   • On the platform’s website, navigate to the Pull Request.

2. Review Changes:

   • Use the platform’s diff viewer to see the changes made in the PR.
   • You can add comments directly on the lines of code to provide feedback or ask questions.

3. Run Tests:

   • If the repository has automated tests, make sure they pass for the PR.
   • You can trigger the tests by clicking the appropriate button on the PR page.

4. Approve or Request Changes:

   • If the changes are acceptable, you can approve the PR.
   • If changes are needed, leave a comment requesting the necessary updates.

3. Merging a Pull Request

Steps:

1. Ensure All Checks Pass:

   • Make sure all automated checks (tests, code quality checks, etc.) have passed before merging.

2. Resolve Conflicts (if any):

   • If there are merge conflicts, the PR creator will need to resolve them in their branch and push the updates.

3. Merge the Pull Request:

   • On the platform’s website, click the “Merge” button.
   • Choose the merge method (e.g., squash and merge, rebase and merge, create a merge commit).

4. Delete the Branch:

   • Optionally, delete the branch from the remote repository to keep things tidy.

4. Closing a Pull Request

Steps:

1. Close Without Merging:

   • If the PR is not suitable for merging, click the “Close” button.
   • Optionally, leave a comment explaining why the PR is being closed.

2. Close After Merging:

   • After merging the PR, the platform usually closes it automatically.

5. Best Practices for Managing Pull Requests

1. Clear Commit Messages:

   • Write descriptive and concise commit messages that explain the purpose of each commit.

2. Regular Reviews:

   • Review PRs regularly to ensure timely feedback and integration of changes.

3. Automated Tests:

   • Ensure that the repository has automated tests in place to validate PRs.

4. Code Quality Tools:

   • Use code quality tools and linters to enforce coding standards.

5. Documentation:

   • Update any relevant documentation along with the code changes.

6. Communication:

   • Keep communication open and friendly. Encourage questions and discussions in PRs.

By following these steps, you can effectively manage Pull Requests, ensuring that code changes are reviewed, tested, and integrated into the main branch smoothly.