git rebase删除的当前文件

发布于 2025-01-28 08:10:33 字数 899 浏览 3 评论 0原文

我一直在与git rebase斗争,不确定它是如何工作的。因此,我所做的是以下步骤:

git checkout main
git pull origin main
git checkout my-branch
git rebase origin/main

然后我在控制台中收到了一些消息,说我需要在继续之前解决冲突。问题是当我打开“红色”文件时,当前的更改或输入更改都不是我在重新命中之前刚刚修改的代码。


<<<<<<< HEAD
.MuiSwitch-root .MuiSwitch-switchBase.Mui-checked {
=======
/* .MuiSwitch-root .MuiSwitch-switchBase.Mui-checked {
>>>>>>> cbfe089 (built skeleton for Settings Page)
    color: var(--primary-clr) !important;
}

.MuiSwitch-switchBase.Mui-checked .MuiSwitch-track {
    background-color: black !important;
    opacity: 1 !important;
    background: linear-gradient(#f4f4f4, #e9e9e9) !important;
<<<<<<< HEAD
}
=======
} */
>>>>>>> cbfe089 (built skeleton for Settings Page)

我对整个文件进行了更改,这些都不是我当前的代码。 另外,我注意到我添加的一些文件也找不到。我不知道发生了什么。

I have been struggling with git rebase and not sure how it works. So, what I did is following steps:

git checkout main
git pull origin main
git checkout my-branch
git rebase origin/main

Then I got some message in console saying I need to resolve the conflicts before continuing. The problem is when I open the "red" file, none of the current change or incoming change is the code that I just modified before I rebase.


<<<<<<< HEAD
.MuiSwitch-root .MuiSwitch-switchBase.Mui-checked {
=======
/* .MuiSwitch-root .MuiSwitch-switchBase.Mui-checked {
>>>>>>> cbfe089 (built skeleton for Settings Page)
    color: var(--primary-clr) !important;
}

.MuiSwitch-switchBase.Mui-checked .MuiSwitch-track {
    background-color: black !important;
    opacity: 1 !important;
    background: linear-gradient(#f4f4f4, #e9e9e9) !important;
<<<<<<< HEAD
}
=======
} */
>>>>>>> cbfe089 (built skeleton for Settings Page)

I made changes for the whole file and none of these are my current code.
Plus, I noticed some of the files I added are also nowhere to be found. I have no idea what is happening.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

爱情眠于流年 2025-02-04 08:10:33

我认为我本身无法帮助您进行冲突,但是我可以解释Rebase的作用,下次可以更好地处理它。假设您的GIT历史记录的状态是:

a <- b <- c <- d <- e <- f <- g
               ^main          ^my-branch (HEAD)

您一直在分支上工作,因此您在主要领先者领先。您最近的工作是在Consits E,F和G中进行的。然后您结帐主,然后将其放在其上。

a <- b <- c <- d <- e <- f <- g
               ^main (HEAD)   ^my-branch

您拉开来/主。事实证明,其他人推动了更新,提交H,I和J。

a <- b <- c <- d <- e <- f <- g
               ^              ^my-branch
               |
               h <- i <- j
                         ^main (HEAD)

当您查看my-branch并运行git rebase rigase rigin/main时,它进行了e,f和g,并在j的结尾处粘在它们:

a <- b <- c <- d 
               ^              
               |
               h <- i <- j <- e <- f <- g
                         ^main          ^my-branch (HEAD)

它通过应用E/f/g来做到这一点 。一个一次是在J处的最重要的。
问题是,如果H/I/J修改了与E/F/G相同的文件,则必须手动解决冲突。这就是为什么您会看到不熟悉的代码。因为您没有写H/I/J,但它仍然可以在冲突中出现。

不幸的是,我无能为力地处理丢失的文件,这听起来像是在解决冲突时可能会意外删除自己的更改(E/f/g中的内容)。

I don't think I can help you with the conflicts themselves, but I can explain what rebase does and it might help you deal with it better next time. Let's say the state of your git history is this:

a <- b <- c <- d <- e <- f <- g
               ^main          ^my-branch (HEAD)

You've been working on your branch so you're ahead of main by a few commits. Your recent work is in commits e, f, and g. Then you checkout main, setting HEAD to it.

a <- b <- c <- d <- e <- f <- g
               ^main (HEAD)   ^my-branch

You pull origin/main. Turns out someone else has pushed updates, commits h, i and j.

a <- b <- c <- d <- e <- f <- g
               ^              ^my-branch
               |
               h <- i <- j
                         ^main (HEAD)

When you checked out my-branch and ran git rebase origin/main, it took commits e, f, and g and stuck them at the end of j:

a <- b <- c <- d 
               ^              
               |
               h <- i <- j <- e <- f <- g
                         ^main          ^my-branch (HEAD)

It does this by applying e/f/g one at a time on top of what's at j.
The problem is that if h/i/j modified the same files as e/f/g, then you have to manually resolve the conflicts. That's why you see code that's unfamiliar to you. Because you didn't write h/i/j, but it can still show up in the conflicts.

I unfortunately can't help with the missing files, that sounds like while resolving the conflicts you might have accidentally deleted your own changes (the stuff in e/f/g).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文