这就是我希望我的工作流在概念层面看起来像:
由于我既懒惰又完美主义者,我希望能够做一些不按顺序的事情:我可能会纠正一个错字,但忘了把它放在评论修复堆中; 当我准备上游补丁(我正在使用git-svn,所以我需要非常慎重)时,我会在那时撤回注释修复.我可能会忘记将事情完全分开,直到最后.但是我可能/也/已经/已经犯下了一些堆(抱歉,这个比喻正在打破......).
这就像只使用带有SVN的Eclipse变更集一样,只有我可以对不同堆中的同一文件进行不同的更改(不得不将更改分解为不同的提交,这是促使我转移到git-svn,实际上......),以及与Git我可以拥有完整的混乱变化历史,实验分支和所有,但仍然做一个漂亮,整洁的补丁.
我最近刚开始和Git一起度过了一段时间,我到目前为止很开心.然而,上述工作流程没有真正映射到Git的最大方式是"bin"实际上不能只是一个本地分支,因为工作树只能反映单个分支的状态.或者Git索引可能是"堆积",我想要的是以某种方式(有效地)拥有多个.
我可以想出几种方法来近似我想要的东西(可能是创造性地使用藏匿物？错综复杂的藏匿 - 合并舞蹈？),但我对Git的掌握并不足以确定如何最好地放置所有碎片一起.据说Git比VCS更像是一个工具包,所以我想这个问题归结为:我如何用这些工具构建这个东西？
听起来你想要做的就是每次单独做一些事情时创建大量的提交,然后git rebase -i在向上游推送它们之前使用它们重新排序和组合你的提交.
该rebase功能是Git真正强大的功能之一,它似乎非常适合您的操作模式.
由于您可以使用更改提交消息rebase,因此可以为每个相关提交添加"标记",如"COMMENT"或"UTILS",这样您可以在以后随机播放内容时轻松识别它们git rebase -i.
其中一个限制git svn dcommit可能很尴尬 - 你只能向补丁发送补丁的"完整"集(从Git的角度来看).也就是说,dcommit只从您开始进行更改的点提交到HEAD.如果你有一些提交(比如你的拼写错误),你想要保留一些以后的批量提交,那么你可以为这些提交临时分支,git rebase以保持它是最新的.
我已经在我的"要做的事情列表"上尝试制作补丁git svn dcommit,让你可以选择发送到Subversion的补丁.