我想從只包含一個提交的分支中洗掉一個提交。
我試圖洗掉那個提交使用，
git reset --soft HEAD~1
git push origin dev --force
我能夠洗掉所有提交。但無法洗掉最后一次提交。
uj5u.com熱心網友回復：
首先，您應該結帳到您的分支機構 git checkout yourbranch
其次，查看以git log --onelineformat 格式顯示提交串列的命令輸出[HASH] commit message。您應該在要洗掉的之前（串列下方）復制提交的提交哈希。
第三，執行git reset --hard [copied hash]，您的分支將重置為之前的提交。
現在，如果您愿意，您可以將分支強制推送到服務器。
uj5u.com熱心網友回復：
使用 git log
然后去另一個分支最有可能的主要分支 git checkout main
把你的提交臨時放在那里
git cherry-pick [commit-hash]
現在你可以簡單地洗掉你的分支
// delete your branch locally
git branch -d [branch-name]
// delete your branch remotely
git push origin --delete [branch-name]
現在你可以使用
git reset --soft HEAD~1
并重新創建您的分支
uj5u.com熱心網友回復：
[使用
git reset,] 我能夠洗掉所有提交。但無法洗掉最后一次提交。
您實際上無法洗掉任何提交。您實際上并沒有洗掉它們，只是讓它們難以找到。上次提交不能這樣做的原因很簡單：分支名稱總是選擇一些提交。在 Git 中，沒有空分支這樣的東西。
事實上，在 Git 中，分支名稱并不重要。它們使我們（人類和 Git 兩者）能夠找到提交，但重要的是提交。為了正確理解這一點，我們必須看看 Git 如何“看到”提交。
Git 存盤庫的核心是一組資料庫：
有一個資料庫，通常是迄今為止最大的，用于存盤提交和其他支持物件。這就是
git clone副本：克隆是大資料庫的副本。（這個資料庫是作為一個資料庫實作的。它是一個簡單的鍵值存盤，其中的鍵是哈希 ID或物件 ID，那些看起來很丑的隨機的東西，
git log列印為提交號。有不止一種型別的內部物件，但提交是你一直看到的。）有一些較小的保存名稱等。這些目前是一種俗氣、蹩腳的實作，不是正確的資料庫，但它們大多像簡單的鍵值存盤一樣作業，其中名稱是鍵，值是那些丑陋的大哈希 ID 之一。
這意味著對于一次提交，每個名稱（在本例中為每個分支名稱）僅包含一個哈希 ID 。
它是形成實際的提交......好吧，這里常用的詞是分支，但我們試圖定義分支，所以讓我們避免使用這個詞，只說“我們關心的東西”。我們知道，基于上述，每個提交的編號用哈希ID。這些哈希 ID 對于提交是唯一的：沒有兩個提交可以具有相同的哈希 ID。1 剩下的我們需要知道的是：
每個提交存盤兩件事：資料——每個檔案的完整快照——和元資料。
在元資料中，Git 存盤一些先前提交的哈希 ID （或提交，復數，用于合并提交，或者至少對于一個特殊情況，沒有先前的提交）。
這使得提交形成向后看的鏈。也就是說，假設我們有一個只有三個提交的小型存盤庫。這三個提交具有看起來隨機的哈希 ID，但為了繪制它們，我們將只使用單個大寫字母：A對于我們所做的第一次提交、B第二次和C第三次提交。
Commit C，在這個 Git 存盤庫中，存盤了commit的實際哈希 ID（無論它是什么）B，它在我們制作C. 所以我們說這C 指向 B：
B <-C
但是 commitB在其內部存盤了較早 commit 的實際哈希 ID A。所以B指向A：
A <-B <-C
CommitA是有史以來的第一次提交，不存盤任何早期的哈希 ID。（Git 稱之為根提交。）它只是獨立的。
要使用這三個提交，我們需要能夠找到它們的哈希 ID。所以 Git 為我們創建了一個分支名稱，如main或dev：
A--B--C <-- dev (HEAD)
在這里，我懶得在提交之間繪制內部箭頭：不過沒關系，因為每個提交的所有部分都是只讀的，一直凍結，包括向后指向的箭頭。由于它們無法改變，我們知道它們指向后。某些未來提交的哈希 ID 是未知且不可預測的，2而過去提交的哈希 ID 是一成不變的，因此可以將舊提交的哈希 ID 刻在石頭上。
如果我們強制名稱dev向后退一步，會發生以下情況：
C
/
A--B <-- dev (HEAD)
Note that commit C isn't deleted. It's just that we find commits by having Git turn a name, such as dev, into a hash ID. The hash IDs stored in names can be changed, and now dev finds B, not C. B points backwards to A, so we only see commits B and C.
Doing this one more time produces:
B--C
/
A <-- dev (HEAD)
Again, no commits have gone anywhere, but now we only see commit A.
We can't make it so that we stop seeing A entirely: if we force dev back to commit B, it reappears, but A is still there, and if we force dev back to commit C, all three commits are back, and A is still there. Or, we could make some new commit D, using any of the existing three as its parent. Using A as its parent gives us:
B--C
/
A
\
D <-- dev (HEAD)
The root commit, in other words, seems to be pretty special. And in fact it is, but it's not so special that we can't do anything about it. There is a flag, --orphan, that we can give to git checkout or git switch that puts us in a special mode.
1Git guarantees this uniqueness only stochastically. That's why the hash IDs are as big and ugly as they are: with only a 1-in-2160 chance of accidental collision between two Git hash IDs, they're "guaranteed" to be unique. The pigeonhole principle tells us that this approach must fail someday, but the size of the hash puts that day far enough into the future to avoid needing to care about it. Or at least, that's the hope here: but that's another topic entirely.
2The actual hash ID is the output of a cryptographic hash function run over all the (meta)data in the commit. This includes unpredictable inputs, such as the date-and-time-stamp that will go on the next commit. Since the hash itself is sensitive to every input bit, and we don't know what the input bits will be, we don't know what the future hash ID will be either. (This is also why we can't change any of the data in the commit: doing so would ruin the hash. Git verifies that the hash ID we use to retrieve the data matches the hash ID obtained when hashing the retrieved data, and thus automatically detects any error.)
Creating a root commit
Let's consider for a moment the case of a new, totally-empty repository:
[no commits at all]
With no commits at all, how can our initial branch name—main or master or whatever it might be—point to some existing commit?
The answer is: It can't. And the rule is: a branch name must point to some commit. So the branch name can't meet its rule.
Git's solution to this problem is simple: don't create the branch name. This means that we are on some branch, main or master, that does not exist. Git calls this, variously, an orphan branch or an unborn branch.
When we are in this state, running git commit will—if it succeeds—write out a root commit and create the branch:
A <-- main (HEAD)
Now we're on branch main, which now exists, and now we have our root commit A.
Suppose we've made three commits, and then made a dev branch (which pointed to C too) and then forced dev all the way back to A:
B--C <-- main
/
A <-- dev (HEAD)
If we'd now like to create a new root commit, we need to create this same on a branch that does not exist yet state. We need an unborn, or orphan, branch:
git checkout --orphan newbranch
Now we can work in the usual way and make a new commit. The new commit will be a new root commit. The existing three commits continue to exist:
B--C <-- main
/
A <-- dev
but we have another new commit, D, that is on our new branch:
D <-- newbranch (HEAD)
and newbranch is (still) our current branch.
You can't delete commits, but you can abandon them
Let's take our repository-so-far:
B--C <-- main
/
A <-- dev
D <-- newbranch (HEAD)
and force the names dev and main to point to commit D, like this:
git branch -f dev HEAD
git branch -f main HEAD
Now we have:
A--B--C
D <-- dev, main, newbranch (HEAD)
All the name find commit D. We can now switch to dev or main and delete the name newbranch, if we like: it's not needed for anything any more, as the other two names find commit D.
What about the three A-B-C commits? The answer to that question is: They're still in the repository, but unless you know or can find their hash IDs, you can't even see them. They are abandoned.
Git will—eventually, someday, maybe—garbage collect (git gc) abandoned commits. The details here depend on a lot of factors. Some hosting sites, like GitHub, are very bad at erasing abandoned commits; others may be better at it. On your own laptop, you can force Git to speed up the usual garbage collection, but by default, abandoned commits will stick around for at least 30 days in case you'd like to get them back.
The mechanism that hangs on to "deleted" commits is called the reflog, and git reflog will show you the saved hash IDs. (This is yet another database, or series of databases, in the repository. You shouldn't rely too much on the exact implementation of any of these name-to-ID databases, as the Git core group are working on new ways to handle them now. The old ways worked well enough for a long time—about two decades now—but the strain is showing in places.)
Conclusion
You can't "eject" the last commit from a branch, because a branch name—which is how we find the commits that form the branch (or "DAGlet", depending on what you mean by the word branch in the first place)—must point to some commit. So no branch is ever truly empty.
Usually when we view a branch, we'd like to view some selected subset of that branch: the commits that we can find, starting from the one found by a branch name, and working backwards until ... some point. By choosing the cutoff point carefully, we can pretend we have an empty branch:
...--G--H <-- main, dev
If we list the commits that are "on" main or dev, it's the same list. If we ask for, say, commits that are on dev, but not on main—which we get with git log main..dev; note the two dots here—then we'll see an empty list. Once we git checkout dev and add new commits:
...--G--H <-- main
\
I--J <-- dev (HEAD)
then main..dev will select just those two commits, J and I, in Git's usual backwards order.
轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/332854.html
上一篇：對檔案所做的任何更改，git都會在.history/中創建未跟蹤的檔案
下一篇：Git未能在標簽上創建分支