标签: git-worktree

我用git-new-workdir一个git存储库有两个工作树.这通常很有效,但是如果在两个工作树中检出相同的分支,我会在提交某些内容后得到有趣的行为:

• 我从干净的工作树和"主人"开始.
• 我在工作树A中做了些什么.

结果:

• 工作树A中的"git status"显示"clean"(如预期的那样)
• 工作树B中的"git status"突然显示"要进行的更改"

显示的更改与我在A中提交的提交相反.例如,如果A中的提交添加了一行,则B中的"要提交的更改"显示此行已被删除.

这里发生了什么？这是git-new-workdir的已知限制吗？有没有办法避免这个问题？或者我应该避免在两个副本中签出同一分支时检入？

我也有兴趣了解内部发生的事情(我对git的内部结构知之甚少).

注意:

我发现git reset--hard如果B在A中提交之前没有未提交的更改,那么只需在B中运行就可以轻松解决问题 .

但是,如果我在A中提交B中存在未提交的更改,则真正未提交的更改会与提交中的伪造更改混合在一起,并且似乎没有简单的方法可以解开它们.因此问题.

我正在尝试执行下面提到的代码。代码创建一个分支，然后从工作树目录完成工作树和提交

代码失败并出现以下错误：

error= exit status 1

如果我直接从命令行执行提交（Cmd3），它工作正常：

sh-3.2# /usr/bin/git -C /Users/gitissue/folder1/Outer commit -m Commiting-from-folder1-Outer
On branch Outer
nothing to commit, working tree clean

脚步：

1. 创建文件夹 /Users/gitissue
2. cd /用户/gitissue
3. git初始化
4. 触摸t.txt
5. git 添加 .
6. git commit -m“提交”
7. mkdir -p /用户/gitissue/folder1
8. 执行下面提到的go代码

环境详情：

• 苹果系统
• git 版本 2.37.0
• go版本go1.18.1 darwin/amd64

代码：

package main

import (
"fmt"
"io"
exec "os/exec"
)

func main() {

Cmd := exec.Command("git", "-C", "/Users/gitissue", "branch", "Outer")
fmt.Print("Cmd1= " + Cmd.String())
err := execBashCmd(Cmd)
if err != nil {
    fmt.Print("error1= …

就在我以为Git不再复杂的时候，我才发现git worktree。这是我不知道的子树或功能的代名词。工作树与子树相同还是不同？如果它们不同，它们又如何不同，工作树将解决什么问题？

我忘了将 .ai 添加到我的 .gitignore 文件中，但是运行 $ git add . 并添加了相当多的.ai文件到索引中。

当我跑起来 $ git status 看到它们时，我想将它们从索引中删除。

匆忙中，我跑了 $ git restore -s@ -SW 导致我所有的.ai文件都从我的工作树中消失了。我不应该使用W.

有什么办法可以找回我的.ai文件吗？

我喜欢 git worktree，但不断遇到本地工作目录与远程分支不同的情况，即使 git pull 说“已经是最新的”。

这是我做的一点 MRE：

• 在 GitLab Web 界面中创建了一个远程存储库。
• 使用克隆它git clone --bare <url>
• main使用本地添加分支git worktree add main
• 添加了一个新分支，使用git worktree add new-branch,cd编辑到其中并执行了git push.
• 使用 GitLab Web 界面，我main-branch-change-1直接在main分支中添加了一个文件，然后new-branch在新的 基础上重新构建main，然后feature-branch-change-1在new-branch.
• git pull在本地new-branch显示“已经是最新的”，而提交哈希并git log清楚地显示本地不是最新的。该文件main-branch-change-1存在，但不存在feature-branch-change-1。
• git fetch --all在裸仓库中紧随其后的git pullinnew-branch没有任何变化。
• git pullinmain分支后跟git pullin …