使用git pull请求为开源项目贡献什么工作流程？ （例如通过Github） [英] What's the workflow to contribute to an open source project using git pull requests? (eg. via Github)
问题描述
我有一个全面的逐步描述，说明我是如何做到这一点的，我想在这里分享它，这样开发人员可以从中受益（我会回答我自己的问题）。
注意：步骤1，步骤2和步骤3只进行一次在一台开发机器上设置一切：
1）确保你在本地工作，而不是指向项目作为原点的克隆存储库。为了分享Github项目，请转到 https://github.com/entity/project ，点击叉，并选择一个适当的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）确保分叉回购的主分支与原始项目回购的主分支同步：
git checkout master
git fetch上游
gi t合并上游/主
git推送原始大师
5）在你的项目fork中创建一个新的分支，用于你想要贡献的特定修复（在bug修复，跟踪器问题，文档部分等之后命名）并切换到它。
git checkout -b myfixes
自动创建分支并切换到它。 确保分支已不存在。您可能还想摆脱已经合并到文档中的旧修复分支（否则，您的项目中会有大量无用的分支）：
git branch -D myoldfixes
git push origin --delete myoldfixes
重要说明：如果您已经在其他计算机上的分支上工作并且想要在新计算机上继续工作，则需要重新执行新计算机上的步骤2，步骤3和步骤4在第5步中，您应该使用 git checkout myfixes 来执行 git checkout -b myfixes b）。否则，你可能会得到一个分离的头部状态，这是不好的（一种匿名分支）
6）分支（例如myfixes）并提交您的更改：
git commit -a -m我的修复程序
（或者您可以在不使用-a的情况下暂存特定文件并提交，在分支中留下未被改变的变化）
7）在您修复修复时，原始上游项目回购可能已经发生变化其他贡献者正在努力）。所以首先你必须从上游目标分支重新绑定你当前的分支（myfixes）。换句话说，您需要在上游repo master分支最新工作之上重播您的修补程序，以确保您的提交仍与上游的最新提交兼容。这将导致我们想要的pull请求的快速合并：
git checkout myfixes
git pull --rebase upstream master
注意：这会导致冲突但这是正常的，修复它们是过程的一部分（这在非常活跃的项目中经常发生）
8） （如果有的话），您已经在最新版本的上游主控制器上应用了修复程序。由于pull请求是从Github上的分叉存储库启动的，因此您希望保持该请求的同步：
git checkout myfixes
git push origin myfixes -f
9）可以去Github https://github.com/yourgithubuser/project 并点击Pull Request。请确保您选择上游回购主作为目的地分公司和您的分支回购myfixes作为源分支（分支将在接受请求后自动移除）
享受！
I have a comprehensive step by step description on how I do this and I wanted to share it here so developers can benefit from it (I'll answer my own question).
Since changes contributed to open source projects will have to be peer reviewed it's common to see a workflow which relies on git pull requests. Pull requests are not allowed from directly cloned repos (you need your own fork). So these are the steps I follow to maintain a healthy fork and contribute to an open source periodically:
Note: Steps 1, 2 and 3 are only done once on a single development machine to set everything up:
1) Make sure you're working locally on your "fork" of the project rather than on a cloned repository pointing to the project as origin. In order to fork a Github project go to https://github.com/entity/project , click on "Fork" and choose a suitable GitHub account for the fork eg. your personal Github account. Note that your forked project "origin" will be no longer the original project repo but your own fork on Github. Be careful with privacy if you're forking a private project since you probably don't want your fork to be public.
2) Clone your own project fork into your development machine.
git clone git@github.com:yourgithubuser/project.git
3) Add the original project repo as upstream repository in your forked project.
git remote add upstream git@github.com:entity/project.git
The original main project repo is now "upstream" but not "origin"
And now comes the work loop that you'll repeat when you work with your forked project:
4) Before starting your work always make sure the master branch of your forked repo is synchronized with the master branch of the original project repo:
git checkout master
git fetch upstream
git merge upstream/master
git push origin master
5) Create a new branch in your project fork for the specific fixes that you want to contribute (name it after either a bugfix, a tracker issue, a documentation section, etc) and switch to it.
git checkout -b myfixes
This automatically creates the branch and switches to it. Make sure the branch does not exist already. You might also want to get rid of your old fix branches that have already been merged into the docs (otherwise you'll have tons of useless branches in your project):
git branch -D myoldfixes
git push origin --delete myoldfixes
Important note: if you were already working on a branch on a different machine and want to continue that work on a new machine you need to redo steps 2, 3 and 4 on the new machine and in step 5 instead of doing git checkout -b myfixes you should do git checkout myfixes (remove the -b). Otherwise you can end up with a "detached head" state which is not good (kind of an anonymous branch)
6) Work on that branch (eg. myfixes) and commit your changes:
git commit -a -m "My fixes"
(Alternatively you can stage specific files and commit without using -a. You can commit as many times as you want but don't leave uncommited changes in the branch)
7) While you were working on your fixes the original upstream project repo might have changed (due to other contributors working on it). So first you'll have to rebase your current branch (myfixes) from the upstream destination branch. In other words you need to replay your fixes on top of that latest work from upstream repo master branch to make sure your commits are still compatible with the latest commits in upstream. This will result in a fast-forward merge for the pull request which is what we want:
git checkout myfixes
git pull --rebase upstream master
Note: this can result in conflicts but this is normal, fixing them is part of the process (this happens more often on very active projects)
8) After fixing the conflicts (if any) of the previous step you have applied your fixes on top of the latest version of upstream master. Since the pull requests are initiated from your forked repository on Github you want to keep that one in sync too:
git checkout myfixes
git push origin myfixes -f
9) Finally, you can go to Github https://github.com/yourgithubuser/project and click on "Pull Request". Make sure you choose upstream repo "master" as the destination branch and your forked repo "myfixes" as the source branch (the branch will be automatically removed for you after the pull request is accepted)
Enjoy!
这篇关于使用git pull请求为开源项目贡献什么工作流程？ （例如通过Github）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
