用于开发fork的Git工作流程

Question

我试图弄清楚我是否应该在我的上游分支克隆上进行开发，或者首先创建它的本地分支，即

1. fork upstream
2. 在我的主人身上工作
3. 针对我的主人发出拉动请求 ......时间过去了......
4. 将upstream / master合并到我的主人
5. 回到2。

或

1. fork upstream
2. 将我的主人分支到dev
3. 致力于开发
4. 针对dev发出pull-request ......时间过去了......
5. 将upstream / master合并到我的主人
6. 重新分配master或将master合并到dev
7. 回到2

我认为第二个工作流程的原因是我的拉​​请求未被接受或仅部分接受的情况，一旦我合并上游我想确保我的本地与上游相同所以我不基于未来的工作关于上游的分歧突变。或者当我从上游拉到掌握以使我的本地主人与之相同时（即丢弃所有本地更改？）

Answer 1

在处理上游回购时，我通常按照我认为您的第二个工作流建议。即：

1. 我从上游的master创建一个分支。如果我正在处理特定的功能或错误，我会将该分支命名为反映;否则，我会称之为dev或诸如此类的。
2. 开发dev，根据需要从上游master进行变基。
3. 推送dev（或我称之为分支的任何内容）并发出我的拉取请求。
4. 继续将上游的更改下拉到我的master分支。

即，我不会在master上进行任何工作。这为上游维护者创建了一个简单，干净的分支/拉取请求。

Answer 2

还有非常重要的git rebase将任何外部更改拉入/合并到您重新绑定的分支。这就是我过去对Qt进行更改的方式（它托管在具有良好合并请求功能的gitorious上）。步骤1和2可能只是你的第二位。

1. 在单独的项目上创建自己的“master”克隆
2. 在当前开发的分支机构工作或创建新的工作分支。
3. 在发出拉取请求之前，请执行git rebase origin/master或类似的操作，以确保您的提交完全适用于当前主服务器。这有一个很好的副作用，你的更改出现在“堆栈顶部”，即在所有其他提交之后。

希望这可以帮助你做你想做的事。