为开源项目贡献代码的最佳实践（最负责任？）是怎样的？

[tlerbao]

声明本人菜鸟一个，下面是我整理的流程，想在 v2 寻求最佳实践 哪里不对请各位大神指点。

Fork

Fork 项目到自己仓库

Clone

克隆到本地

git remote add upstream

添加上游 remote 用来时刻保持和上游同步

git pull upstream master

每次开发前都拉取最新代码（好习惯？）

git checkout -b dev-branch

不在 master 开发，新建分支开发

git checkout master && git pull upstream master

代码开发完成再拉一次

git checkout dev-branch

切换回开发分支

git rebase master

这是我新学的。以前我都是直接切回 master 然后 merge 开发分支 push 的 我目前理解的作用是将我的修改放到上游 commit 的最后。 如果上游并没有更新这部可以不用？用了也没效果。

git push origin dev-branch

将开发分支推送到远程仓库

pull request

发起 pull request 等待合并

删除分支

这种比如贡献一个小功能或者修复一个 bug 的分支何时能删除？ 正确的删除方式？ git push origin --delete dev-branch ？

[yizmaoaa]

挺好的做法。

我在提 Pr 的时候很简单粗暴

fork -> clone 下来修改 ->写测试用例 -> 跑测试用例 ->提交代码 -> 发 Pr

删除分支的话，等项目合并你 Pr 之后就可以干掉了

我往往是这样的，如果我之前 Fork 过这个项目，然后我再需要提 Pr 的时候我直接删除我 fork 的仓库，重新 fork 。

另外，cherrypick 也是一个很好的功能

[dddddd]

保持和上游同步我是用的 github 的 pull request 方式 ，这样能方便的解决冲突，而且很清晰

[renmu123]

我是新建一个分支开发完直接上 github 提 pr

[monkeyWie]

不用切回 master 做 pull，直接 git fetch+git rebase upstream/master

[genius2k]

fork, 开两个分支，一个 dev，一个 master
master 永远只用 git reset --hard 和 upstream 保持完全一致
dev 用来开发新特性，每完成一个新特性，先同步 master 然后从 master 开出一个新的 patch，再 merge dev 到 patch 。这样保证提交的 patch 可以用最少的 effort 合并
rebase 偶尔用，但主要是用来 squash dev 上的阶段性代码或者 reword commit message

[yupozhang]

开源运维平台： https://github.com/openspug/spug
欢迎参与贡献。