缺少git commit [英] Missing git commit

查看:83
本文介绍了缺少git commit的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

它总是在工作中发生,某人不小心将某些东西提交给了主人,而不是交给了预定的功能分支,然后该人试图解决它,只是使更改突然消失.我经过反复搜索,找不到文档说明这种情况的发生原因或解决方法.

It happens all the time at work, that someone accidentally commits something to master instead of to the intended feature branch, the person then tries to resolve it, only to have the changes suddenly disappear. I have searched thick and thin, and can find no documentation to shed light on why this happens, or how to remedy the situation.

以下是复制步骤:

$ git init
$ echo hello world > testfile
$ git add testfile
$ git commit -m 'init'
$ git branch A
$ echo abc >> testfile
$ git commit -am 'append abc'
$ git revert HEAD --no-edit
$ git checkout A
$ echo fff > secondfile
$ git add secondfile
$ git commit -m 'Add second file'
$ git cherry-pick master^

此时git历史记录如下:

At this point the git history looks like this:

$ git log --oneline --all --graph --decorate
* ac6f9b4 (HEAD -> A) append abc
* 54be952 Add second file
| * 9ba1f16 (master) Revert "append abc"
| * ef7c8d6 append abc
|/  
* 65a885d init

然后观察当我将分支A重新建立在master之上时会发生什么:

Watch then what happens when I rebase branch A on top of master:

$ git rebase master
$ git log --oneline --all --graph --decorate
* 9d08739 (HEAD -> A) Add second file
* 9ba1f16 (master) Revert "append abc"
* ef7c8d6 append abc
* 65a885d init

位于A头的提交ac6f9b4发生了什么情况?去哪了为什么不重新应用?

What happened to the commit that was at the head of A, commit ac6f9b4? Where did it go? why wasn't it reapplied?

虽然这只是一个小示例,但最后一次缺少单个提交,但有时我们最终会从一个较长的提交链中丢失几个提交,然后它们似乎实际上是不可见的:(

While this was just a small example with a single commit missing on the end, but sometimes we end up losing several commits from the middle of a long commit chain, and then they seem practically invisible :(

推荐答案

Rebase不会重新应用已经在新基础中应用的提交-这是您的append abc更改.它已经在主人的历史上了.这经常是正确的,以至于git无需评论就可以做到这一点.可以说,至少在后续还原的情况下值得一提.

Rebase doesn't re-apply commits that have already been applied in the new base -- here, it's your append abc change. It's already in the master history. This is so often right that git does this without comment. It's arguably at least worth mentioning in the presence of subsequent reverts.

要查看您变基础的内容是否已经包含在新的基本历史记录中(此处为master

To see whether anything you're rebasing is already part of the new base history (master, here),

git log --oneline --cherry ...master

并查找带有=标记的提交.这些是master中的提交,与您分支中的提交匹配;重新设置基准不会重新应用它们.将master...换为...master,以查看本地等效项.

and look for =-marked commits. Those are commits in master that match commits in your branch; rebase won't re-apply them. Swap master... for ...master to see the local equivalents.

如果您想要有效地盲目调整底价,则第一个切入点是

If you want an effectively blinded rebase, a first cut is

git checkout -B A master
git cherry-pick ..A@{1}      # < added the very important `..` by edit

这只是将A移到母版上,然后将您刚刚剩下的所有内容都挑选出来.要忽略合并(您可能应该这样做),请在Cherry-Pick中添加--no-merges,结果是当您要求Cherry-Pick进行一系列操作时,它会将整个集合传递给git rev-list,因此您可以直接使用机器:

which just moves A onto master and then cherry-picks everything you just left behind. To ignore merges (which you probably should), add --no-merges to the cherry-pick, it turns out when you ask cherry-pick for a series it just passes the whole set to git rev-list so you can use the machinery directly:

git cherry-pick --no-merges ..A@{1}  # just learned now that cherry-pick takes this

这篇关于缺少git commit的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆