如何fork项目以及做后续的开发

github其中一个最大的好处是你可以很容易fork一个项目，然后你自己就可以修改它。最糟糕的一点是，你不再获得以后这个项目的更新。

然后，你的本地修改pull request到一个经常有提交的项目，然后不可避免地必须要合并补丁。以下是根据我自己的经验写的，关于如何简单地处理这种情况。

第一步： 设置远端仓库

如果你运行git remote -v，你可以看到你的远端仓库的地址信息，一般名字为orgin，执行git push的时候就是push到这个地址。 我们为了方便和这个地址打交道，可以给它起一个名字：

git remote add upstream https://github.com/ORIGINAL_OWNER/ORIGINNAL_REPOSITORY.git

然后你就可以通过upstream 引用远端仓库

第二步：经常同步远端仓库

当你要开始写一些新的代码的时候，首先可以先同步远端仓库，然后你就可以获得最新的提交，避免后面你的提交有冲突。

git fetch upstream

git checkout master

git merge upstream/master

git push

然后你的代码应该能轻易地合并过去 只是一个“fast-forward”，而不是真的做一个合并提交。当然，你要严格按照我下面的建议去做。

第三步：一定不要提交到master分支

如果你想要一个简单 干净的工作流，那么你一定不要提交到你的本地master分支。你的本地master分支应该仅仅是作为追踪你的远端分支用的，这样你才能总是简单干净地在你的当前版本工作并且简单地合并pull requests.相反，你应该在你的分支上进行修改。

当你push你的分支到远端的时候，你可以PR；当你的PR被接受了，你可以pull下来最新的更新，然后删除你的分支。master仅仅是作为远端的代码追踪，不要污染它。

第四步：经常Rebase你的分支

假设你正在分支上做一个新功能，然后你留意到远端也就是upstream有些新的改动，这些改动和你的要改的代码的位置一样。所以，你要合并远端的代码，以免后面会冲突。那么，怎么做呢？

首先，同步你的代码按照步骤2。然后rebase你的当前分支：

git checkout MY_COOL_BRANCH

git rebase master

这样会撤销你的提交，然后从远端获取代码，然后把你的提交应用在新的代码上面。这样，当你PR的时候，远端的代码维护者就能轻易的合并，因为你的代码是在最新的代码上的。

第五步：强制提交解决很多的fix xx提交记录

当你最终要PR的时候，代码review的时候，你很可能需要fix一个错误。你可以代码改好后然后提交到PR的分支，但是当合并的时候回有很多“fix xx”的提交记录。不要这样弄，这样，你可以修改你的提交，用git commit –amend ，然后强制提交到远端仓库，用git push –force.强制push不是一个好主意，但是通常这个是一个主意，避免出现合并错误拒绝提交。但是这里我们只是改了提交历史，并不会有大问题，反而让提交的记录更干净了。

翻译自：http://www.xanthir.com/blog/

文章名： Cleanly Handling a Fork on GitHub

作者： Tab Atkins Jr