我不确定这叫什么，或者这是否是一个坏主意，所以如果我问错了问题，请教育我。
我有一个代码库，我正在帮助改进它，这是我从 github 克隆的。我想首先清理 Eclipse 报告的一些明显警告，然后检查并清除所有已弃用的成员调用。
为了帮助作者简化事情，我想提交多个拉取请求以在代码中进行类似的修改，而不是一个"清理大量内容"，以便他们更容易检查和批准。
我一直在做的是保留他们的原始代码作为主代码，并为每组类似的更改制作新的分支。我遇到的问题是，浏览 IDE 报告的警告/错误列表非常混乱，因为每次我移动到不同的组时，我都会切换回主节点的一个分支，并且我在另一个分支中修复的问题再次可见。
是否可以只处理一个大的"一切"分支，以便更容易忽略我已经修复的内容？例如，每个"提交"都会被制作成一个单独的分支。
或者.. 在一个分支上工作，合并了我所有其他分支修复程序，然后在我完成我在其他地方所做的更改后取消合并它们。
我问的有意义吗？有没有这方面的工作流程？
一种简单的方法（但有一个问题）是根据您自己的分支而不是/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
只有一个问题。请注意，我只将"create PR"放在第一个分支之后，而不是其他分支之后。您应该仅在前一个 PR 被接受后创建下一个 PR。这样，只有新的提交才会显示在审阅者的差异中。
这很简单，我每天都在我的项目中在实践中使用它。
不要误会我的意思，我通常基于 origin/master 创建新分支，但只有在新分支依赖于挂起的 PR 的特殊情况下，我才会基于该 PR 分支创建新分支。
您只需从主分支创建一个分支即可。
然后，对于每组更改，只需将新的提交添加到分支即可。这样可以轻松删除提交或查看单个提交的更改（如果需要）。
如果 master 已更新，则可以将一个分支重新定位到主分支之上。
这是交互式变基的工作。 在您自己的分支上进行更改，但当时对您来说很有意义。 然后，当您准备好提取某些工作时，执行交互式变基，将准备好的更改移动到分支前面的提交系列，使用分支提示名称标记最后一个更改，以便他们可以提取这些更改，然后继续：
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