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

问题描述

您能否提供一份(所有或最常见的)操作或命令的列表，这些操作或命令可能会破坏 git 中的历史记录?

应该绝对避免什么?

1. 在推送此提交后修改提交 (git commit/git push/git commit --amend)
2. 转向已经推动的东西

我希望这个问题(如果在其他地方之前没有问过的话)成为关于 git 上常见可避免操作的某种参考.

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

解决方案

，但总有一种风险，您会忘记那些无法访问的提交，或者无法识别 reflog 的哪个条目对应于提交 D.

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

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

What should be absolutely avoided?

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

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.

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 has already compiled a good list of the commands that rewrite history, but I wanted to build upon his answer.

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.

Operations that should count as rewriting/deleting the history of a local repo

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.

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'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: 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 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.

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.

Operations that rewrite/delete the history of a remote repo

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.

That said, it is possible to

• 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.

---

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?

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:

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

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.

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.

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.

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屋！