Question

我不确定这是什么，或者这是一个坏主意，所以如果我要问错误的问题，请教育我。

我有一个代码库，我帮助改进了我从github克隆的代码库。我想首先清理Eclipse报告的一些明显警告，然后清除所有已弃用的成员调用。

为了帮助简化作者的工作，我想在代码中提交多个拉取请求以进行类似的修改，而不是一个＆＃34;大量的东西被清理干净＆＃34;所以他们更容易检查和批准。

我一直在做的是将原始代码保留为主代码，并为每组类似更改创建新分支。我遇到的问题是，通过IDE报告的警告/错误列表非常困惑，因为每次我移动到另一个组时，我都会切换回一个分支。我在另一个分支中修复的主人和问题再次可见。

是否可以只使用一个大的＆＃34;一切＆＃34;分支，以便更容易忽略我已经解决的事情？例如，每个＆＃34;提交＆＃34;将成为主人的一个单独的分支。

或..在我的所有其他分支修复程序合并的分支上工作，然后在我完成其他地方所做的更改时取消合并。

我问的问题有意义吗？是否有工作流程？

Answer 1

一个简单的方法（但有一个catch）是根据你自己的分支而不是/master创建新的分支。例如：

git checkout -b obvious-warnings origin/master
# work work work, create PR

git checkout -b deprecated-calls
# work work work

git checkout -b fix-findbugs
# work work work

只有一个问题。请注意，我只是把＃＆＃34;创建PR＆＃34;在第一个分支之后，而不是其他分支。您应该只在已经接受上一个PR之后创建下一个PR。这样，只有新的提交才会出现在评论者的差异中。

这很简单，我每天都会在我的项目中使用它。

不要误解我，我通常会根据origin/master创建新的分支，但只有在新分支依赖于待处理的PR的特殊情况下，我才会根据该PR创建新分支分支。

Answer 2

您可以简单地从主分支创建一个 branch。

然后，对于每组更改，只需在分支上添加新的提交。这样可以在需要时轻松删除提交或查看单个提交的更改。

如果更新了master，您可以rebase将您的一个分支重新安装在主服务器上。

Answer 3

这是interactive rebase的工作。在您自己的分支上进行更改但是当时对您有意义。然后，当您准备将某些工作拉下来时，执行交互式rebase将准备好的更改移动到分支前面的提交系列，使用分支提示名称标记最后一个，以便它们可以拉动只是那些，并继续：

git checkout -b cleanup
# work work commit commit lalala
# others do the same on master

...o... .... X---Y     master   #
    \
     Mon-Tue-Wed-Thu   cleanup  # this branch not for publication

git rebase -i master
# (move commits and hunks as you like here, the whole point is you can
# work on an overview of a complete set of work and make it ready for 
# presentation/publishing)

...o... .... X---Y     master
                  \
                   A---B   for-upstream  # branch made during a rebase -i `edit` or `exec` stage
                        \
                         j---k---l   cleanup

我可以在一个分支上工作，其中包含从其他分支合并的补丁吗？

3 个答案: