这是一个创建于 1596 天前的主题，其中的信息可能已经有所发展或是发生改变。
声明本人菜鸟一个，下面是我整理的流程，想在 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 条回复 • 2020-07-16 14:17:10 +08:00
 |
1
yizmaoaa 2020-07-16 11:32:11 +08:00
挺好的做法。
我在提 Pr 的时候很简单粗暴 fork -> clone 下来修改 ->写测试用例 -> 跑测试用例 ->提交代码 -> 发 Pr 删除分支的话，等项目合并你 Pr 之后就可以干掉了 我往往是这样的，如果我之前 Fork 过这个项目，然后我再需要提 Pr 的时候我直接删除我 fork 的仓库，重新 fork 。 另外，cherrypick 也是一个很好的功能 |
 |
2
dddddd 2020-07-16 11:40:40 +08:00
保持和上游同步我是用的 github 的 pull request 方式 ，这样能方便的解决冲突，而且很清晰
|
 |
3
renmu123 2020-07-16 13:05:08 +08:00 via Android
我是新建一个分支开发完直接上 github 提 pr
|
 |
4
monkeyWie 2020-07-16 13:32:10 +08:00
不用切回 master 做 pull，直接 git fetch+git rebase upstream/master
|
 |
5
genius2k 2020-07-16 13:47:09 +08:00
fork, 开两个分支，一个 dev，一个 master
master 永远只用 git reset --hard 和 upstream 保持完全一致 dev 用来开发新特性，每完成一个新特性，先同步 master 然后从 master 开出一个新的 patch，再 merge dev 到 patch 。这样保证提交的 patch 可以用最少的 effort 合并 rebase 偶尔用，但主要是用来 squash dev 上的阶段性代码或者 reword commit message |
 |
6
yupozhang 2020-07-16 14:17:10 +08:00
开源运维平台： https://github.com/openspug/spug
欢迎参与贡献。 |
Select Language