为开源项目贡献代码的最佳实践(最负责任?)是怎样的?

tlerbao2020-7-16161

声明本人菜鸟一个,下面是我整理的流程,想在 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 ?

最新回复 (6)
  • yizmaoaa2020-7-20
    引用2
    挺好的做法。

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

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

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

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

    另外,cherrypick 也是一个很好的功能
  • dddddd2020-7-20
    引用3
    保持和上游同步我是用的 github 的 pull request 方式 ,这样能方便的解决冲突,而且很清晰
  • renmu1232020-7-20
    引用4
    我是新建一个分支开发完直接上 github 提 pr
  • monkeyWie2020-7-20
    引用5
    不用切回 master 做 pull,直接 git fetch+git rebase upstream/master
  • genius2k2020-7-20
    引用6
    fork, 开两个分支,一个 dev,一个 master
    master 永远只用 git reset --hard 和 upstream 保持完全一致
    dev 用来开发新特性,每完成一个新特性,先同步 master 然后从 master 开出一个新的 patch,再 merge dev 到 patch 。这样保证提交的 patch 可以用最少的 effort 合并
    rebase 偶尔用,但主要是用来 squash dev 上的阶段性代码或者 reword commit message
  • yupozhang2020-7-20
    引用7
    开源运维平台: https://github.com/openspug/spug
    欢迎参与贡献。
  • 游客
    8
返回