这种分散注意力的工作流程可以在 Git 中实现吗？
这就是我希望我的工作流程在概念层面上看起来像这样：
- 我对我的新功能进行了一段时间的修改
- ，我注意到评论中有一个拼写错误
- 我改变它
- 由于拼写错误与其他任何内容完全无关，因此我将这一更改放入一堆评论修复中
- 我继续研究代码
- 我意识到我需要充实一些实用功能
- 我这样做
- 我把这个变化单独放在一堆
- 步骤 2、3 和 4 每一天都重复
- 我完成了新功能，并将该功能的更改放在一堆中
- 我向上游推送了不错的补丁：一个新功能，一些其他调整，以及一堆评论修复（如果积累了足够多的话）
因为我既懒惰又完美主义者，我希望能够做一些不按顺序做的事情：我可能会纠正一个拼写错误但忘记将其放入评论修复堆中；当我准备上游补丁时（我正在使用 git-svn，所以我需要对这些进行深思熟虑），然后我将在此时提取评论修复。我可能会忘记把事情完全分开，直到最后。但我可能/也/一路上犯了一些错误（抱歉，这个比喻已经失效了……）。
这就像使用 Eclipse 变更集和 SVN 一样，只有我可以对不同堆中的同一个文件进行不同的更改（事实上，必须将更改分解为不同的提交，这就是促使我转向 git-svn 的原因……），并且使用 Git，我可以拥有完整混乱的更改历史记录、实验分支等等，但仍然可以制作出漂亮、整洁的补丁。
在想了很长一段时间之后，我最近才开始使用 Git，到目前为止我很高兴。然而，上述工作流程并未真正映射到 Git 的最大方式是，“bin”实际上不能只是本地分支，因为工作树仅反映单个分支的状态。或者，Git 索引可能是一堆“一堆”，而我想要的是以某种方式（有效地）拥有多个索引。
我可以想出几种方法来近似我想要的（也许创造性地使用存储？复杂的存储-结帐-合并舞蹈？），但我对 Git 的掌握不够扎实，无法确定如何最好地放置所有部分一起。据说 Git 与其说是一个 VCS，不如说是一个工具包，所以我想问题归结为：我如何使用这些工具构建这个东西？
This is what I'd like my workflow to look like at a conceptual level:
- I hack on my new feature for a while
- I notice a typo in a comment
- I change it
- Since the typo is completely unrelated to anything else, I put that change in a pile of comment fixes
- I keep working on the code
- I realize I need to flesh out a few utility functions
- I do so
- I put that change in its own pile
- Steps 2, 3, and 4 each repeat throughout the day
- I finish the new feature and put the changes for that feature in a pile
- I push nice patches upstream: One with the new feature, a few for the other tweaks, and one with a bunch of comment fixes if enough have accumulated
Since I'm both lazy and a perfectionist, I want to be able to do some things out of order: I might correct a typo but forget to put it in the comment fix pile; when I prepare the upstream patches (I'm using git-svn, so I need to be pretty deliberate about these), I'll then pull out the comment fixes at that point. I might forget to separate things altogether until the very end. But I might /also/ have committed some of the piles along the way (sorry, the metaphor is breaking down …).
This is all rather like just using Eclipse changesets with SVN, only I can have different changes to the same file in different piles (having to disentangle changes into different commits is what motivated me to move to git-svn, in fact …), and with Git I can have my full discombobulated change history, experimental branches and all, but still make a nice, neat patch.
I've just recently started with Git after having wanted to for a good while, and I'm quite happy so far. The biggest way in which the above workflow doesn't really map into Git, though, is that a “bin” can't really be just a local branch, since the working tree only ever reflects the state of a single branch. Or maybe the Git index is a “pile,” and what I want is to have more than one somehow (effectively).
I can think of a few ways to approximate what I want (maybe creative use of stash? Intricate stash-checkout-merge dances?), but my grasp on Git isn't solid enough to be sure of how best to put all the pieces together. It's said that Git is more a toolkit than a VCS, so I guess the question comes down to: How do I build this thing with these tools?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
听起来您想要做的是每次单独执行某些操作时创建大量提交，然后使用
git rebase -i在将提交推向上游之前重新排序和组合您的提交。rebase功能是 Git 真正强大的功能之一，而且它似乎非常适合您的操作模式。由于您可以使用
rebase更改提交消息，因此您可以向每个相关提交添加一个“标签”，例如“COMMENT”或“UTILS”，这样当您稍后使用 <代码>git rebase -i。git svn dcommit的限制之一可能很尴尬 - 您只能向 Subversion 发送一组“完整”补丁（从 Git 的角度来看）。也就是说，dcommit仅从您开始进行更改的点提交到 HEAD。如果您想保留一些提交（例如拼写错误）以供以后的批量提交使用，那么您可以为这些提交创建一个临时分支，使用 git rebase 来保持最新状态。我在我的“有时要做的事情列表”中尝试为 git svn dcommit 制作一个补丁，让你选择将哪些补丁发送到 Subversion。
It sounds like what you want to do is to create lots of commits each time you do something separate, and then use
git rebase -ito reorder and combine your commits before pushing them upstream.The
rebasefunction is one of the really powerful features of Git, and it seems well suited to your mode of operation.Since you can change commit messages with
rebase, you could add a "tag" like "COMMENT" or "UTILS" to each related commit, so you can easily identify them later when you shuffle things around withgit rebase -i.One of the limitations of
git svn dcommitmay be awkward - you can only send up a "complete" set (from a Git point of view) of patches to Subversion. That is,dcommitonly commits from the point you started making changes, to the HEAD. If you have commits (like your typos) that you want to keep around for some later batch commit, then you can make a temporary branch for those, usinggit rebaseto keep it up to date.I have on my "list of things to do sometime" to try to make a patch for
git svn dcommitthat lets you choose which patches to send up to Subversion.