考虑一下我们将以下命令应用于hello.txtgit 下跟踪的文件（在干净的工作副本中）：
echo "hi" >> hello.txt
mv hello.txt bye.txt
git rm hello.txt
git add bye.txt
git status
结果：
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
renamed: hello.txt -> bye.txt
因此，git 知道它是同一个文件，即使它被重命名了。我有一些模糊的记忆，git 检查 inode 以确定新文件与旧的已删除文件相同。 不过，这个和这个SO 答案表明 git 只检查文件的内容，并且不会以任何方式检查它是否是相同的 inode。（我的结论（*）：如果我对文件进行更大的修改，git 将不会检测到重命名，即使 inode 仍然相同。）
因此，在我看来，很明显，我错了，git 不检查 inode（或任何其他文件系统信息），只检查内容。但后来，我发现了另一个答案，它声称
除了时间戳之外，它[即git]还记录lstat的大小、inode和其他信息，以减少误报的机会。当您执行 git-status 时，它只需对工作树中的每个文件调用 lstat 并比较元数据，以便快速确定哪些文件未更改。
我对此实际上有两个问题：
Git 确实依赖（也）依赖 inode 来检测文件是否已更改，但它不使用 inode 来检测文件重命名。
我曾多次听到Git保留了"它所知道的变化"的内部记录.这通常是为什么我们需要将更改(比如登台到修改程序的修补程序)或重新定位中固有的问题重新编写.我觉得这就像"一流的对象",其中使用的短语有点含糊不清并且松散地使用,并且潜在的现实更为直接.
那么"它所知道的变化"到底意味着什么呢？在Git源代码中,每个分支都维护一个sha1的列表,它"知道"(可能在这里:https://github.com/git/git/blob/master/commit-graph.c)？当Git更改sha1时会发生什么 - 例如,说发布分支上的某个人做了a,b,c的壁球提交来制作d？
发布分支是否知道a,b,c,并且在合并回dev时它是否也会传递该信息或仅存在d？如果dev分支已经提交了一个 - 它是否足够智能来同时管理d和a的存在？
我知道我可以通过使用git reset --merge或使用git merge --abort. git merge 的手册页说明了中止选项“当存在 MERGE_HEAD 时，git merge --abort 等效于 git reset --merge。”。我猜 MERGE_HEAD 仅在合并正在进行时才存在，这也是我解决冲突时的情况。当我提交更改时，据我所知 MERGE_HEAD 消失了。什么附加功能git reset --merge或git merge --abort当 MERGE_HEAD 消失时？我在存储库上尝试过，但git reset --merge在 MERGE_HEAD 消失后看不到它的效果。那么git merge man page的这句话是什么意思呢？
提前致谢。
Git 将文件存储为 blob，然后使用 SHA-1 校验和作为密钥在其他 blob 中查找每个特定 blob，类似于标识文件的文件名。
那么这个黑魔法是如何运作的呢？也就是说，如何从一个文本文件开始并以一个 blob 结束？是通过取消引用文件的内存地址创建的 blob 还是其他什么？
在我的本地仓库中，我有 3-4 个分支，当我处理其中一个分支时，我在其中所做的更改会传播到我所有的其他分支。事实上，如果我是git reset --hard origin其中之一，它会重置每个本地分支。
我应该如何将我的更改限制在一个分支中？
请注意，我是 git 的菜鸟。
git pull 是指 git fetch 然后是 git merge。但是，具体来说，为什么有人会在不先进行 fetch 的情况下进行 git merge 呢？即为什么可以将一个看似单一的操作分成两个子操作？
我对 git 有点陌生，试图了解分支/rebase 是如何工作的，以及是否有可能我搞砸了一些事情。
我和我的同事都在不同的分支机构，我需要他为我的工作所做的改变。所以我拉了他的改变。然后我做了
git rebase -i HEAD~3
并删除了我不需要的他的提交。然后我向我们的存储库推送并创建了一个拉取请求，一切看起来都很好。看起来就像是我需要他的更改和我自己的更改的一项提交。
我还没合并呢 是否有可能一旦他合并，然后我合并，不知何故，因为我删除了他在我正在合并的分支上的提交，它删除了他的代码？
我正在尝试更新提交消息，但同时保持相同的哈希值。
我尝试了 --message-callback 和 --commit-callback 这两个选项，但无论我选择哪一个，它都会生成新的哈希值。我是这样做的：
python3 git-filter-repo.py --preserve-commit-hashes --message-callback (or --commit-callback) '
if b"blabla" not in message:
message = b"MyMessage " + message
return message' --force
这是一种错误吗？或者我做了一些完全错误的事情？
任何帮助表示赞赏
我想知道使用 git sha 指向依赖项的特定版本是否安全。我知道这不是一个好的做法，但有时是必要的。
我已经读到，通常情况下，不可能选择提交 ID，因为它是使用很多东西自动计算的。但没有人提到你可以在本地重建 git 来覆盖这个算法，让我们生成重复的 sha。
我没有读到 gitserver 检查它以确保 gitclient 没有“损坏”，就是这样。
那么，假设上述情况是可能的（请确认与否），sha git是否就被认为是sicured呢？
我在这里看到代码
https://gist.github.com/Srfigie/77b5c15bc5eb61733a74d34d10b3ed87
#Image
*.jpg filter=lfs diff=lfs merge=lfs -text
*.jpeg filter=lfs diff=lfs merge=lfs -text
*.png filter=lfs diff=lfs merge=lfs -text
*.gif filter=lfs diff=lfs merge=lfs -text
*.psd filter=lfs diff=lfs merge=lfs -text
*.ai filter=lfs diff=lfs merge=lfs -text
*.tif filter=lfs diff=lfs merge=lfs -text