标签: git-index

仍然很难让我的脑袋围绕着舞台的概念,因为它适用于Git.

可以用SVN进行任何类比吗？在Git中拥有阶段级别的主要目的是什么？

在开发过程中,我经常将文件的工作版本(但不提交它们)添加到我的git repo中.我继续处理这些文件,直到它们达到可执行阶段,当我可以提交它们时.所以回购看起来如下

$ git status

# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   modified:   testfile1
#
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   testfile1
#   modified:   testfile2

当我做一个git stash,然后做一个git stash pop,我得到

# On branch master
# Changes not staged for …

从这张图中，提交是指向根树的指针，根树是指向其他树和 blob 的指针。但什么是正确的指数观呢？

问题：

• 它是具有文件夹结构的类似树状结构还是只是斑点的平面视图？

• 如果索引是树状的，那么提交和索引之间有很大区别吗？

• 索引看起来更像是完整快照还是差异？

我对git索引包含的内容有一个模糊的概念,就像git-adds和git-commits一样,但我不知道当一个人做a时这些内容会发生什么git-merge.我特别感兴趣的是在合并失败时(例如由于某些冲突)了解索引的含义.

您可能想跳过序言。

我有一个具有以下结构的 npm 包：

lib/index.js
src/index.coffee

源文件是一个 CoffeeScript 文件。我有一个用于从源文件构建 JavaScript 文件的 make 目标。直到最近，我在每次提交中都包含了对 JavaScript 文件的更改，但我现在将xyz与预发布脚本一起使用：

XYZ = node_modules/.bin/xyz --script scripts/prepublish

.PHONY: release-major release-minor release-patch
release-major: LEVEL = major
release-minor: LEVEL = minor
release-patch: LEVEL = patch

release-major release-minor release-patch
    @$(XYZ) --increment $(LEVEL)

预发布脚本很简单：

#!/usr/bin/env bash
set -e

rm -f   lib/index.js
make    lib/index.js
git add lib/index.js

这意味着每次我发布新版本（make release-patch例如通过运行）时，lib/index.js将被重建并添加到发布提交中。一切正常，直到这一点。

由于发布脚本会自动更新编译后的文件，我不再想每次提交时都手动更新它。问题是运行后make test，git status将lib/index.js列为修改后的跟踪文件。我想避免意外提交这个文件，所以我想防止它被git status.

我尝试的第一件事是添加/lib/到.gitignore。但是，这不起作用，因为 …

在阅读如何使用 Git 时，我发现git index.

他们是：

• directory cache
• current directory cache
• staging files
• staging area

为什么有这么多选项可以准确地命名一件事？

我应该如何命名它以免混淆我不知道背景的未来对话者？

我手头没有特定的问题，但是在过去的某些情况下，我偶然遇到了意外破坏索引的情况，希望我可以返回给定文件的先前状态，该状态在某个时刻被索引了。

一些示例情况是：

$ git add <file>
# find out that I already had an indexed version of <file>,
# and that for some reason I shouldn't have added the extra modifications

$ git stash pop
# find out afterwards that I have a mix of "the index I had"
# and "the index in the stash"

$ git stash
# with an active index, which is now mixed with the state of the working tree

$ git reset <typo>
# …

当发生冲突时，git status显示如下：

Unmerged paths:
  (use "git restore --staged <file>..." to unstage)
  (use "git add <file>..." to mark resolution)
    both modified:   some_file

现在我可以git add some_file按照命令的建议标记解决方案，但这也会阶段化some_file，我可能不想这样做。

如何标记文件以进行解析而不将其添加到索引中？只需两步即可轻松完成：

git add some_file
git restore --staged some_file

但如果可能的话，我该如何一步完成呢？

如果最佳实践不建议这样做，请告诉我。

我使用git gui来选择要为提交暂存的行.这通常像魅力一样.我知道在命令行上执行相同操作的选项.

每当文件最初在文件末尾没有新行时,git gui会识别出这一点并在编辑器中附加警告消息,如屏幕截图所示.

问题

缺少换行符导致的问题是人们不能再分段和提交单独的行.当我右键单击以选择特定行并Stage line for commit从上下文菜单中选择时,会弹出一条错误消息.

错误:致命:第11行腐败的羊皮纸.

该问题并非特定于操作系统,可以在Windows,MacOSX和Linux上重新生成.我知道如果我在文件中添加新行并在继续选择单行之前提交此版本,我可以避免此问题.

重现问题的步骤

1. 初始化新存储库.
2. 创建一个包含三行内容的文件,每行包含"Hallo"一词.不要在文件末尾添加新行.
3. 添加并提交文件.
4. 编辑相同的文件,在三行之间放置单词.
5. 打开git gui并尝试逐行进行更改.

请求

我想知道Git是否有一些配置允许我绕过这个问题.一些自动化,例如添加所需新线的钩子也可以.

错误报告

我向Git邮件列表发送了一个错误报告.您可以关注并参与此处的讨论.

我的Git目录中的大多数文件都是纯文本文件(压缩的松散对象和packfiles除外).这样我就可以猫和编辑文件,如.git/HEAD或.git/refs/heads/master与检查库,如果它被破坏.

但这.git/index是一个二进制文件.纯文本文件不是更有用,因为它可以很容易地手工修改吗？

Scott Chacon在他的演讲中展示了以下图片(幻灯片278):

在我看来,这很容易被放到一个纯文本文件中.

那么为什么它是二进制文件而不是纯文本文件？