我对如何执行此操作有一个全面的逐步说明，我想在此处分享，以便开发人员可以从中受益（我将回答我自己的问题）。
答案 0 :(得分：55)
由于对开源项目的贡献必须经过同行评审，因此通常会看到依赖于git pull请求的工作流。直接克隆的repos不允许提取请求（您需要自己的fork）。因此，这些是我遵循的步骤，以保持健康的分叉并定期为开源做出贡献：
注意：步骤1,2和3仅在一台开发机器上完成一次以设置所有内容：
1）确保您在项目的“分支”上本地工作，而不是在指向项目作为原点的克隆存储库上工作。为了分叉Github项目，请转到https://github.com/entity/project，单击“Fork”并为分叉选择合适的GitHub帐户，例如。您的个人Github帐户。请注意，您的分叉项目“origin”将不再是原始项目仓库，而是您自己在Github上的分支。如果你要私人项目，请小心隐私，因为你可能不希望你的分支是公开的。
2）将您自己的项目分支克隆到您的开发机器并进入该目录。
git clone git@github.com:yourgithubuser/project.git
3）在分叉项目中将原始项目仓库添加为上游存储库。
git remote add upstream git@github.com:entity/project.git
原来的主要项目回购现在是“上游”而不是“原产地”
现在，当您使用分叉项目时，您将重复工作循环：
4）在开始工作之前，请务必确保forked repo的master分支与原始项目repo的master分支同步：
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）当您处理修补程序时，原始上游项目仓库可能已更改（由于其他贡献者正在处理它）。首先，您必须从上游目标分支重新定义当前分支（myfixes）。换句话说，您需要在上游repo master分支的最新工作之上重放您的修复，以确保您的提交仍然与上游的最新提交兼容。这将导致拉取请求的快进合并，这是我们想要的：
git checkout myfixes
git pull --rebase upstream master
注意：这可能会导致冲突，但这是正常的，修复它们是流程的一部分（这种情况在非常活跃的项目中更常发生）
8）修复上一步的冲突（如果有）后，您已将修复程序应用于最新版本的上游主服务器。由于拉取请求是从Github上的分叉存储库启动的，因此您希望保持同步：
git checkout myfixes
git push origin myfixes -f
9）最后，你可以去Github https://github.com/entity/project（原来的项目而不是你的叉子）并点击“Pull Request”。确保选择上游repo“master”作为目标分支，并将forked repo“myfixes”选为源分支（在接受pull请求后，将自动删除分支）
享受！
答案 1 :(得分：0)
6a）提交消息的提交和格式主题也很重要。
提交主题应该只涵盖一个逻辑更改。例如，如果您要描述对某人的更改（例如，在提交消息中，请参见下文），您应该无法使用“和”一词来描述该主题，例如。 不“修复错误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>.