相关疑难解决方法(0)

假设我要撤消先前提交引入的所有更改.

据我所知,git reset --hard <specified commit>将删除所有提交,直到指定的提交,并撤消所有更改.
另一方面,git checkout <specified commit>将更改我的目录以反映指定的提交.

所以,如果我git reset之后git checkout会有与之相同的结果git reset --hard吗？

或者,如果我git commit之后git checkout,新创建的提交是否会覆盖现有的提交？

我正在使用git源代码存储库和处于凌乱状态的当前代码,并希望切换到其他分支以进行一些工作.问题是我不想仅仅做半完成的工作,所以我怎样才能在以后回到这一点.

好的，所以我打算在一个名为 的分支上工作directory-layout，但事实证明我正在一个名为master. 这是个问题。

我还没有表演git add .也没有git commit -m "I've made a horrendus mistake I'm sorry"

我该怎么做才能将我的更改添加到另一个（或新的）分支，为什么？

情况图片：您从远程存储库获取数据，并与具有一些未暂存文件的远程源运行 git merge。

git merge 对未暂存文件的行为如何？

如果我运行（例如）

git checkout stash@{0} -- .

...任何相对于索引修改的隐藏文件都会显示为暂存的。这是一个简单的例子：

% git init demo
Initialized empty Git repository in /tmp/demo/.git/
% cd demo
% date >> file.txt
% git add file.txt
% git commit --allow-empty-message -m ''
[master (root-commit) e46cee5] 
 1 file changed, 1 insertion(+)
 create mode 100644 file.txt
% date >> file.txt
% git stash
Saved working directory and index state WIP on master: e46cee5 
HEAD is now at e46cee5 
% git checkout stash@{0} -- .
% git status
On branch master …

我遇到了以下三种方法来取消由命令 'git add' 暂存的文件

git rm --cached <file>
git restore --staged <file>
git reset <file>

当我一一运行这些命令时，它们的行为看起来完全相同。它们之间究竟有什么区别？

我正在学习 git，并且对在主题分支中创建的暂存文件在签出到 master 时不会被删除这一事实感到惊讶。

例如：

git checkout -b topic
nano newfile.txt
git add newfile.txt
git checkout master // newfile.txt is still in the working directory, even though it was created in topic branch

我很了解git clean命令，只是我希望如果您签出到不同的分支，所有从未提交的文件都会被删除。

我在这里遗漏了一些东西还是这是 git 的预期行为？

假设我有一个 git 存储库，在某些分支上工作，并且在某些时候我不想签出任何分支。我可以这样做吗？

换句话说，我可以git clone path-to-repo --no-checkout在现有存储库上获得 , 但的效果吗？

编辑：实际上，如果主分支文件不显示为已删除，那就更好了。因此，理想的答案并不git clone像--no-checkout.

注意：如果您的建议需要最新版本的 git，请说明。

如果我想创建一个新分支，我会这样做：

git checkout -b new-branch

然而，有时这个分支已经存在，例如：

fatal: A branch named 'new-branch' already exists.

有比执行以下操作更简单的方法吗？

git branch -D new-branch
git checkout -b new-branch

我尝试了这个，但它不起作用：

git checkout -b new-branch --force

考虑一下我们将以下命令应用于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 并比较元数据，以便快速确定哪些文件未更改。

我对此实际上有两个问题：

1. 我下面的理解正确吗？

Git 确实依赖（也）依赖 inode 来检测文件是否已更改，但它不使用 inode 来检测文件重命名。

2. 假设 1. 是正确的。为什么 git 不依赖 inode …