Git 的索引概念如何改进或改变您的工作流程？
我已经尝试在我的个人项目中使用 Git 近一个月了。
我对基本命令集有很好的理解，虽然它的用户体验不是很好，但我仍然发现自己比我过去使用过的其他 VCS 更喜欢 Git。
然而，我仍然认为我还没有“理解”一个概念，那就是该指数的真正目的。我有这样的感觉，我没有利用它旨在赋予的一些好处。
设立暂存区的目的是什么？来自 SVN 土地，我非常习惯将我的工作副本视为我的暂存区域，并从中获取我的提交快照。
所以，我的问题是：
这种额外的间接级别会给您带来什么？ Index 如何改进或改变您的正常工作流程？您能否提供一些场景，在这些场景中，有了索引，您就可以完成一些在没有索引的情况下会很麻烦的事情？
I've been trying to use Git on my personal projects for almost a month now.
I have a pretty good understanding of the basic set of commands and while its user experience isn't awesome, I still find myself liking Git more than the other VCS's I've used in the past.
However, one concept that I still don't think I have "gotten" is the real purpose of the Index. I have this feeling I'm not taking advantage of some benefit it is intended to bestow.
What is the purpose of having a staging area? Coming from SVN land, I'm so used to treating my working copy as my staging area and my snapshots for my commits being taken from this.
So, my question is:
What does this extra level of indirection give you? How has the Index improved or changed your normal workflow? Can you provide any scenarios where having the Index has allowed you to do something that would have been troublesome to do without it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
肯定有这样的时候，当我开始致力于一项功能或错误修复时，然后注意到一个快速的打字错误或其他一些微小的（可能是一行）需要修复的事情。我可以通过索引提交只是那个微小的更改，而不是放弃所有工作，甚至使用 git stash ；我的所有其他工作仍然在那里，但现在提交更加具体：它只显示了一个小修复，而不是被淹没在数十行其他更改中。它是为了更清晰的历史记录而设计的，这使得在日志中搜索更改变得很容易，因为它们不会与其他提交混合在一起。
如果发生（复杂的、大的）合并冲突，能够将我所做的每个更改添加到索引中也很好，这样我就知道我已经修复了哪些冲突以及哪些冲突需要处理。
There're definitely times when I start working on a feature or a bug fix, and then notice a quick typo or some other tiny (perhaps one-line) thing to fix. Instead of dropping all my work, or even using
git stash, I can just commit that just that tiny change via the index; all my other work is still there, but now the commit is more specific: it only shows that small fix, instead of getting buried in dozens of other lines of changes. It's made for a much cleaner history, which makes it easy to search logs for changes since they're not mixed in with other commits.In the event of (complicated, large) merge conflicts, it's also nice to be able to add each change I make to the index, so I know what conflicts I've fixed and which ones are left to deal with.
就我个人而言，我目前正在经历一场大规模的合并冲突，我必须一项一项地修复这些项目。在这种情况下，我可以对已合并的文件执行“git add”，并且仍然单独跟踪需要修复的文件。
一旦完成这些，我就可以执行测试编译，然后在提交到存储库之前重新添加所需的任何其他更改。
Speaking personally, I'm undergoing a massive merge conflict at the moment, and I'm having to fix the items one by one. In this case, I can perform a 'git add' on the files that I've merged, and still keep a separate track of the ones that I need to fix.
Once I've gone through that, I can execute test compiles and then re-add any additional changes that are needed, before I commit to the repository.
有时我会执行“gitcherry-pick-n”或“gitmerge--squash”从外部分支中提取一堆更改，然后我将取消所有这些更改并使用git交互式添加（gitadd- i) 只上演我想要的作品。您甚至可以阶段选择差异的“块”，并将其余部分保留在更改的状态（非常适合对应该单独提交的事物进行去卷积）。
当您正在编辑一大堆文件时也很棒，但您决定在继续之前确实应该将与 X 相关的所有文件作为单个提交提交，因此您只需暂存这些文件，提交并继续处理其他文件。
我还喜欢暂存区域与合并一起工作的方式，以向您展示未自动暂存的内容。当然，索引区域对此并不是严格必要的，但我发现 diff 的默认行为仅向您显示非索引项的差异是有用的，因此除非您使用 diff，否则您不会为查看舞台内容而烦恼 - - 缓存。
Sometimes I'll do a 'git cherry-pick -n' or 'git merge --squash' to pull in a bunch of changes from a foreign branch then I'll unstage all those changes and use git interactive add (git add -i) to stage only the pieces I want. You can even stage select "hunks" of a diff and leave the rest in a changed state (great for de-convolving things that should have been seperate commits).
Also great when you are editing a whole bunch of files but you decide you really ought to commit all the files related to X as a single commit before you go any further, so you just stage those, commit and keep working on the other files.
I also like the way the staging area works with merges to show you what didn't get staged automatically. Sure, the index area isn't strictly necessary for this but I find the default behavior of diff showing you a diff of only the non-index items to be useful so you aren't bothered with seeing the stage stuff unless you use diff --cached.