在二等分之前将工作树更改为特定提交的最佳方法是什么?

发布于 2024-08-19 04:33:11 字数 449 浏览 8 评论 0原文

启动 git bisect 会话时我通常的工作流程是:

git bisect start          # start a bisect session
git bisect bad            # I noticed that the current state is broken

现在,我经常知道过去的事情是有效的,但我还不知道哪个版本很好,所以我通常想恢复我的工作树到较旧的状态,构建,测试,重复,直到找到一个可以使用 git bisect good 标记的工作版本。

执行“将我的工作树恢复到较旧状态”步骤的最佳方法是什么? git reset --hardgit checkout?还有别的事吗?请证明你的答案合理。

My usual workflow when starting a git bisect session is:

git bisect start          # start a bisect session
git bisect bad            # I noticed that the current state is broken

Now, often I know that things worked in the past, but I don't know yet which version was good, so I usually want to revert my working tree to an older state, build, test, repeat until I find a working version which I can mark with git bisect good.

What's the best way to do the "revert my working tree to an older state" step? git reset --hard <some_good_rev>? git checkout <some_good_rev>? Something else? Please justify your answer.

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

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

发布评论

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

评论(2

半仙 2024-08-26 04:33:11

我通常不知道好的转速在哪里,所以我必须找到它。猜猜要追溯到多远可能比较好。比方说,32 转。从分支的尖端开始,使用干净的工作目录:

$ git checkout HEAD~32

运行测试。如果转速不错,就开始平分。如果不是,请再返回:

$ git checkout HEAD~32

冲洗,起泡沫,重复。

为什么要“git checkout”?因为“git reset”将更改分支指向的提交作为其“提示”,但 git checkout 不会。

I usually don't know where the good rev is, so I've got to find it. Guess how far back might be good. Let's say, 32 revs. Starting from the tip of a branch, and with clean working directories:

$ git checkout HEAD~32

Run the test. If it's a good rev, start bisecting. If it's not, go back some more:

$ git checkout HEAD~32

Rinse, lather, repeat.

Why "git checkout?" Because "git reset" will change which commit the branch points to as its "tip", but git checkout will not.

逆蝶 2024-08-26 04:33:11

如果您不确定该功能在哪个版本中起作用(引入该功能的提交?),您似乎会失去很多(全部?)平分的好处。如果您确实知道至少有一次提交使该功能有效,即使它不一定是该功能有效的最新提交,只需将该提交标记为良好即可。否则,你基本上就是在把自己一分为二。

If you don't know for sure any version where the functionality worked (the commit that introduced the functionality?), you seem to lose a lot (all?) of the benefit of a bisect. If you do know that there was at least one commit where the functionality worked, even if it isn't necessarily the most recent commit where the functionality worked, just flag that one as good. Otherwise, you're basically doing a bisect yourself.

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