【发布时间】：2014-01-06 17:54:20
【问题描述】：
我对我如何做到这一点有一个全面的分步描述，我想在这里分享它，以便开发人员可以从中受益（我会回答我自己的问题）。
【问题讨论】：
标签： git github open-source pull-request
【发布时间】：2014-01-06 17:54:20
【问题描述】：
由于对开源项目所做的更改必须经过同行评审，因此通常会看到依赖于 git pull 请求的工作流程。不允许从直接克隆的 repos 中提取请求（您需要自己的 fork）。因此，我遵循以下步骤来维护一个健康的分叉并定期为开源做出贡献：
注意：步骤 1、2 和 3 仅在单个开发机器上为每个项目执行一次以设置所有内容。
注意 2：如果您将贡献的开源项目不使用 master 作为默认工作分支，您将必须替换步骤 4) 和 7 的命令中对“master”的所有引用) 下面带有该分支的名称（例如 main）。
1) 确保您在本地处理项目的“分支”，而不是在指向作为源的项目的克隆存储库上工作。要分叉 Github 项目，请转到 https://github.com/entity/project，单击“分叉”并为分叉选择合适的 GitHub 帐户，例如。您的个人 Github 帐户。请注意，您的分叉项目“起源”将不再是原始项目存储库，而是您自己在 Github 上的分叉。如果您要分叉一个私人项目，请注意隐私，因为您可能不希望您的分叉公开。
2) 将您自己的项目 fork 克隆到您的开发机器中，然后 cd 进入该目录。
git clone git@github.com:yourgithubuser/project.git
3) 将原始项目存储库添加为您的分叉项目中的上游存储库。
git remote add upstream git@github.com:entity/project.git
原来的主项目仓库现在是“上游”而不是“起源”
现在是您在处理分叉项目时将重复的工作循环：
4) 在开始工作之前，请务必确保您的分叉存储库的主分支与原始项目存储库的主分支同步：
git checkout master
git fetch upstream
git merge upstream/master
git push origin master
5) 在您的项目分支中为您想要贡献的特定修复创建一个新分支（以错误修复、跟踪器问题、文档部分等命名）并切换到它。
git checkout -b myfixes
这会自动创建分支并切换到它。 确保分支不存在。您可能还想摆脱已经合并到文档中的旧修复分支（否则您的项目中将有大量无用的分支）。您可以通过发出git branch 来查看您的本地分支，如果在该列表中您找到已与上游项目合并的分支，那么您可以这样做：
git branch -D myoldfixes
git push origin --delete myoldfixes
重要提示：如果您已经在另一台机器上的分支上工作并希望在新机器上继续该工作，您需要在新机器上重做步骤 2、3 和 4，然后在第 5 步中，而不是执行 git checkout -b myfixes 您应该执行 git checkout myfixes（删除 -b )。否则你可能会以一个不好的“分离头”状态结束（一种匿名分支）
6) 在该分支上工作（例如 myfixes）并提交您的更改：
git commit -a -m "My fixes"
（或者，您可以暂存特定文件并在不使用 -a 的情况下提交。您可以根据需要多次提交，但不要在分支中留下未提交的更改）
7) 在您进行修复工作时，原始上游项目 repo 可能已更改（由于其他贡献者正在处理它）。所以首先你必须从上游目标分支重新定位你当前的分支（myfixes）。换句话说，您需要在上游 repo master 分支的最新工作之上重播您的修复，以确保您的提交仍然与上游中的最新提交兼容。这将导致我们想要的拉取请求的快进合并：
git checkout myfixes
git pull --rebase upstream master
注意 3：这可能会导致冲突，但这是正常的，修复它们是过程的一部分（这种情况在非常活跃的项目中更常见）
注意 4：如果您在分支中有很多提交，并且您是一个体贴的人，您可能想squash your commits into a single one 以使原始项目的维护者受益
8) 修复上一步的冲突（如果有）后，您已将修复应用到最新版本的上游 master 之上。由于拉取请求是从您在 Github 上的分叉存储库发起的，因此您也希望保持同步：
git checkout myfixes
git push origin myfixes -f
9) 最后，你可以去Github https://github.com/entity/project（原项目不是你的fork）点击“Pull Request”。确保您选择上游仓库“master”作为目标分支，您的分叉仓库“myfixes”作为源分支（在拉取请求被接受后，该分支将自动为您删除）
享受吧！
【讨论】：
-
您在 4) 中更新原始主机。您可能会在该合并中发生冲突，但如果您总是这样做 4) 在开始处理 repo 之前，那么合并是不费吹灰之力
-
这是我最近遇到的另一个场景。我打开了一个
new-feature分支，在该分支上我有 2 个提交，new-feature-basic（添加了基础知识）和new-feature-on-steroid（基于基础知识并添加了一些细节）。我希望 repo 维护者能够只接受new-feature-basics提交，以防他不想要细节。我还要为整个分支创建 PR 吗？ -
拉取请求是每个分支。您可以为这两个分支发送两个拉取请求，并告诉维护者“保留您喜欢的一个，拒绝另一个”。不过我不建议这样做，尝试一次发送一个 PR！
-
@pomber 我现在看到了。我相信你强制推送更新 origin/myfixes 是正确的，我按照你的建议添加了 -f
6a)提交的主题和提交信息的格式也很关键。
提交主题
提交主题应仅涵盖一项逻辑更改。例如，如果您要向某人描述更改（例如在提交消息中，见下文），您不应该使用“和”一词来描述主题，例如。 not "修复错误 123 并更新配置默认值。"这些应该是两个单独的提交。
如果您在工作树中解决了一堆单独的问题但未提交，那么交互式添加是一个很好的工具。让你的手指记住这批命令，然后按照指示进行操作：
git add -i
5<CR>
*<CR>
您可以更喜欢其他选项，但这意味着“向我展示我的工作树中的每一个变化，然后让我选择要暂存的内容。”
然后，像往常一样：
git ci
提交消息
您希望在标题中简洁明了，以便人们浏览历史，同时还为未来（包括六个月后的您自己！）深入研究涉及您的问题的人提供身体的详细信息改变。
我最喜欢的编写好提交消息的指南是Erlang/OTP wiki page on good commit messages，此外我还要补充一点，使用以下格式不会出错：
Short (<50 chars) present-tense summary of changes
Previously, <a couple sentences clearly describing the previous behavior
and the resulting customer issue>.
This commit <a sentence or two clearly describing the code change, and the
resulting expected behavior>.
【讨论】：