可能会破坏/重写历史记录的Git命令 [英] Git commands that could break/rewrite the history

问题描述

您能否提供可能危害git历史记录的(所有或最常见)操作或命令的列表?

Can you provide a list of (all, or the most common) the operations or commands that can compromise the history in git?

应该绝对避免什么?

1. 在推送此(git commit/git push/git commit --amend)后修改提交
2. 根据已经推动的事情

1. Amend a commit after a push of this one (git commit/git push/git commit --amend)
2. Rebase toward something that has already pushed

我希望这个问题(如果尚未在其他地方问过)成为 git 上常见可避免操作的某种参考.

I would like this question (if it has not already asked before somewhere else) to become some kind of reference on the common avoidable operations on git.

此外，我经常使用git reset，但并不完全意识到我可能会对存储库(或其他贡献者副本)造成的损害. git reset会危险吗?

Moreover I use git reset a lot, but am not completely aware of the possible damage I could do to the repository (or to the other contributors copies). Can git reset be dangerous?

推荐答案

knittl 已经编制了一份很好的清单重写历史的命令，但我想以他的回答为基础.

knittl has already compiled a good list of the commands that rewrite history, but I wanted to build upon his answer.

您可以提供可能危及git历史记录的操作或命令的列表吗?应该绝对避免什么?

Can you provide a list of [...] the operations or commands that can compromise the history in git? What should be absolutely avoided?

首先，重写/删除历史记录本身并没有什么问题；毕竟，您可能会例行创建要素分支，严格将其保留在本地，然后删除(在合并它们或意识到它们无所适从之后)，而无需三思而后行.

First of all, there is nothing wrong with rewriting/deleting history per se; after all, you probably routinely create feature branches, keep them strictly local, then delete (after merging them or realising they lead you nowhere) without thinking twice about it.

但是，当您在本地重写/删除其他人已经可以访问的历史记录并将其推送到共享远程服务器时，您肯定会遇到问题.

However, you can and certainly will run into problems when you locally rewrite/delete history that other people have already access to and then push it to a shared remote.

当然，有一些愚蠢的方式来破坏或删除历史记录(例如，篡改.git/objects/的内容)，但是这些都不在我的回答范围之内.

Of course, there are dumb ways of corrupting or deleting history (e.g. tampering with the contents of .git/objects/) , but those are outside the scope of my answer.

您可以通过多种方式重写本地存储库的历史记录. Pro Git书的标题为 重写历史的部分> ，提到了一些

You can rewrite history of a local repo in various ways. The section of the Pro Git book entitled Rewriting history, mentions a few

• git amend --commit
• git rebase
• git filter-branch
• Roberto Tyley的BFG回购清洁器(第三方工具)

• git amend --commit
• git rebase
• git filter-branch
• Roberto Tyley's BFG Repo Cleaner (a 3rd-party tool)

可以说还有更多.任何可能更改或以其他方式移动非符号引用(分支或标签)并使其指向该分支的当前提示的后代不是的提交的操作均应视为重写本地历史.这包括:

Arguably, there are more. Any operation that has the potential to alter or otherwise move a non-symbolic reference (branch or tag) and make it point to a commit that is not a descendant of the branch's current tip should count as rewriting local history. This includes:

• git commit --amend:替换上一次提交；
• 所有形式的变基(包括git pull --rebase)；
• git reset(请参见下面的示例)；
• git checkout -B和git branch -f:将现有分支重置为其他提交；
• git tag --force:重新创建一个具有相同名称但可能指向另一个提交的标记.

• git commit --amend: replaces the last commit;
• All forms of rebase (incl. git pull --rebase);
• git reset (see an example below);
• git checkout -B and git branch -f: resets an existing branch to a different commit;
• git tag --force: recreates a tag with the same name but potentially pointing to another commit.

任何删除非符号引用(分支或标签)的操作也可以视为历史删除:

Any deletion of a non-symbolic reference (branch or tag) may also be considered history deleting:

• git branch -d或git branch -D
• git tag -d

• git branch -d or git branch -D
• git tag -d

可以说，删除已完全合并到另一个分支中的分支应该被认为仅仅是历史删除的一种温和形式.

Arguably, deleting a branch that has been fully merged into another should be considered only a mild form of history deleting, if at all.

不过，标签是不同的.删除轻量级标签没什么大不了的，但是删除带注释的标签(这是一个真正的Git对象)应该算作删除本地历史记录.

Tags are different, though. Deleting a lightweight tag is not such a big deal, but deleting an annotated tag, which is a bona fide Git object, should count as deleting local history.

据我所知，只有git push -f(相当于git push --force)有可能重写/删除远程存储库中的历史记录.

As for as I know, only a git push -f (equivalent to git push --force) has the potential to rewrite/delete history in the remote repository.

也就是说，有可能

• 通过在服务器上设置receive.denyNonFastForwards，禁用将远程分支强制更新为非快进引用的功能.
• 通过在服务器上设置receive.denyDeletes，禁用删除位于远程存储库中的分支的功能.

• disable the ability to force-update remote branches to non-fast-forward references, by setting receive.denyNonFastForwards on the server.
• disable the ability to delete a branch living on a remote repository, by setting receive.denyDeletes on the server.

此外，我经常使用git reset，但并不完全意识到我可能会对存储库(或其他贡献者副本)造成的损害. git reset会危险吗?

Moreover I use git reset a lot, but am not completely aware of the possible damage I could do to the repository (or to the other contributors copies). Can git reset be dangerous?

如 knittl 所述，

git-reset通常会更改分支引用指向的位置.该命令可能会很危险，因为它可以使可到达的提交变得不可到达.因为图片说出一千个单词，所以请考虑以下情况:

git-reset, as mentioned by knittl, usually changes where a branch reference points. This command can be dangerous, in so far as it can make reachable commits become unreachable. Because a picture speaks a thousand words, consider the following situation:

您位于master分支上，该分支指向提交D.现在，举例来说，您运行了

You're on the master branch, which points at commit D. Now, let's say you run, for instance,

git reset master~2

软重置被认为是最良性的重置形式，因为它仅"更改当前分支指向的位置，但不影响暂存区或工作树.也就是说，仅以这种方式更改分支指向的位置会产生后果:在进行软重置后，您最终会得到

A soft reset is considered to be the most benign form of reset, because it "only" changes where the current branch points to, but doesn't affect the staging area or your working tree. That said, merely changing where a branch points to in that fashion has ramifications: after that soft reset, you will end up with

提交C和D，它们在重置之前从master可以访问，但现在变得不可用；换句话说，它们不是任何引用(分支，标签或HEAD)的祖先.您可以说他们在"存储库边缘"中；它们仍然存在于您的Git存储库的对象数据库中，但是它们将不再列在git log的输出中.

Commits C and D, which were reachable from master before the reset, have now become unreachable; in other words, they're not ancestors of any reference (branch, tag, or HEAD). You could say that they're in "repository limbo"; they still exists in your Git repo's object database, but they will no longer be listed in the output of git log.

如果您在重置之前确实发现了那些有价值的提交，则应通过提供一些引用(例如，另一个分支)来再次提交D，使它们再次可访问.否则，当Git运行其自动垃圾收集并删除无法访问的对象时，提交C和D将最终死于真正的死亡.

If you actually found those commits valuable before the reset, you should make them reachable again by making some reference (e.g. another branch) point to commit D again. Otherwise, commits C and D will end up dying a true death when Git runs its automatic garbage collection and deletes unreachable objects.

从理论上讲，您可以从 reflog 中提交D ，但是总会有风险，您会忘记那些无法到达的提交，或者无法识别reflog的哪个条目对应于提交D.

You can, in theory, fish commit D out of the reflog, but there is always a risk that you will forget about those unreachable commits or won't be able to identify which entry of the reflog corresponds to commit D.

最后，是的，git-reset可能很危险，并且最好确保要重置的分支的当前尖端在重置后仍可访问.如果需要，在重置之前在该处创建另一个分支，以防万一，作为备份；并且如果您确定要忘记这些提交，则以后可以随时删除该分支.

In conclusion, yes, git-reset can be dangerous, and it's a good idea to make sure the current tip of the branch you're about to reset will remain reachable after the reset. If needed, create another branch there before the reset, just in case, as a backup; and if you're sure you want to forget those commits, you can always delete that branch later.

这篇关于可能会破坏/重写历史记录的Git命令的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！