我有以下擔憂。我正在一個分支上作業（我們稱之為 A），在那里我實作了一個新功能。我只提交了更改，但我沒有推動它們。現在我后來意識到我在錯誤的分支上。所以我換到了正確的分支（B）。如何將更改從分支 A 轉移到分支 B？
這樣，到目前為止的所有東西都保留在 B 中，而 A 中所有新的東西都存放在 B 中。
uj5u.com熱心網友回復：
如果：
- 對于某些提交，您確實喜歡某些東西，但是
- 對于這些相同的提交，您還有其他不喜歡的地方
那么通常解決此問題的正確方法是使用git rebase. 總是有一個關于 的警告git rebase，我稍后會描述，但是由于您還沒有將這些提交發送到其他Git 存盤庫 - 您想要以某種方式更改的提交完全是您的，存在于您自己的僅限 Git 存盤庫 - 此警告不適用于您的情況。
不過，在您的特定情況下，您根本不需要使用 rebase。相反，您將想要使用git cherry-pickand thengit reset或git branch -f。或者，您甚至可能不需要進行挑選。
關于提交（以及一般的 Git）需要了解的內容
Git 真的是關于commits 的。這是不是檔案，盡管提交做到保持檔案。它也與分支無關，盡管分支名稱可以幫助我們（和 Git）找到提交。不過，歸根結底，重要的只是提交。這意味著您需要了解有關提交的所有資訊。
在 Git 中：
每個提交都有編號，具有唯一但又大又丑又隨機的哈希 ID或物件 ID。這些實際上根本不是隨機的：數字是加密哈希函式的輸出。每個 Git 都使用相同的計算，因此宇宙中任何地方的每個 Git 都會同意某個特定提交獲得該數字。沒有其他提交可以擁有該編號，無論它是什么：該編號現在已被該特定提交用完。由于數字必須是普遍唯一的，因此它們必須很大（因此很難看，人類無法使用）。
Git 將這些提交以及支持提交的其他內部物件存盤在一個大資料庫中——一個鍵值存盤——其中一個哈希 ID 是鍵，提交（或其他物件）是值。你給 Git 密鑰，例如，通過從
git log輸出中剪切和粘貼，Git 可以找到提交并因此使用它。這通常不是我們實際使用 Git 的方式，但重要的是要知道：Git 需要密鑰，即哈希 ID。每個提交存盤兩件事：
每次提交都存盤每個檔案的完整快照，截至您創建它的時間。這些檔案以特殊的、只讀的、僅限 Git 的、壓縮和重復資料洗掉的格式存盤，而不是計算機上的普通檔案。根據您的作業系統，Git 可能能夠存盤您的計算機實際上無法使用或提取的檔案（例如，
aux.h在 Windows 上命名的檔案），這有時是一個問題。（當然，您必須在可以命名這些檔案的作業系統上創建這些檔案，例如 Linux。不過，這一切的目的只是為了表明這些檔案不是常規檔案。）每個提交還存盤一些元資料，或關于提交本身的資訊：例如，誰提交，何時提交。元資料包括
git log顯示的日志訊息。對于 Git 來說至關重要的是，每個提交的元資料包括一個串列——通常只有一個條目長——以前的提交哈希 ID。
由于 Git 使用的散列技巧，任何提交——任何型別的內部物件——一旦被存盤就不能被更改。（這也是檔案存盤的作業方式，也是 Git 對檔案進行重復資料洗掉并可以存盤您的計算機無法存盤的檔案的方式。它們都只是那個大資料庫中的資料。）
同樣，提交的元資料存盤了一些先前提交的哈希 ID。大多數提交在此串列中只有一個條目，并且該條目是此提交的父項。這意味著 child commits 記住了他們父母的名字，但父母不記得他們的孩子：父母在他們被創造的那一刻被時間凍結，他們的孩子的最終存在無法添加到他們的記錄中。但是當孩子出生時，父母存在，所以孩子可以保存其父母提交的編號。
這一切意味著提交形成向后看的鏈，其中最新的提交指向下一跳到下一個最新的，并且該提交指向另一跳，依此類推。也就是說，如果我們繪制一個小的提交鏈，其最后一次提交具有 hash H，我們得到：
... <-F <-G <-H
哈希為H保存所有檔案快照的提交，以及元資料；H讓 Git 找到 commit的元資料G，因為H指向它的父級G。CommitG依次保存所有檔案和元資料的快照，并且其G元資料指向F. 這一直重復到第一次提交，這是第一次提交，不能向后指向。它有一個空的父串列。
git log因此，程式只需要知道一個提交哈希 ID，即H's。從那里，git log可以顯示H，然后向后移動一跳到G并顯示G。從那里，它可以移回另一跳到F，依此類推。當您厭倦了閱讀git log輸出并退出程式時，或者當它一直回到第一次提交時，操作就會停止。
分支名稱幫助我們找到提交
這里的問題是我們仍然需要以某種方式記住 commit 的哈希 ID，H鏈中的最后一個。我們可以把它記在白板、紙上或其他東西上——但我們有一臺電腦。為什么不讓計算機為我們保存哈希 ID？這就是分支名稱的全部含義。
在 Git 中，每個分支名稱只保存一個哈希 ID。無論分支名稱中的哈希 ID 是什么，我們都說該名稱指向該提交，并且該提交是該分支的提示提交。所以：
...--F--G--H <-- main
here we have the branch name main pointing to commit H. We no longer need to memorize the hash ID H: we can just type in main instead. Git will use the name main to find H, and then use H to find G, and G to find F, and so on.
Once we do this, we have an easy way to add new commits: we simply make a new commit, such as I, so that it points back to H, and then write I's hash ID into the name main like this:
...--F--G--H--I <-- main
Or, if we don't want to change our name main, we make a new name, such as develop or br1:
...--F--G--H <-- br1, main
Now that we have more than one name, we need to know which one we're using to find commit H, so we'll draw in the special name HEAD, attached to one of the branch names, to show that:
...--F--G--H <-- br1, main (HEAD)
Here we're using commit H through the name main. If we run:
git switch br1
we get:
...--F--G--H <-- br1 (HEAD), main
Nothing else changes—Git notices that we're moving "from H to H", as it were—and so Git takes some short-cuts and doesn't bother doing any other work for this case. But now we're on branch br1, as git status will say. Now when we make a new commit I, we'll get this:
I <-- br1 (HEAD)
/
...--F--G--H <-- main
The name main stayed in place, while the name br1 moved to point to new commit I.
Your situation as you've described it
I was working on a branch (let's call it A) where I implemented a new function. I have only committed the changes, but I did not push them. Now I realized later that I am on the wrong branch. So I changed to the right branch (B). How can I transfer the changes from branch A to branch B?
Let's draw this:
...--G--H <-- br-A (HEAD), main
\
I--J <-- br-B
You were on branch br-A and made a new commit, which we'll call K:
K <-- br-A (HEAD)
/
...--G--H <-- main
\
I--J <-- br-B
There are some things that you do like about commit K: for instance, its snapshot differs from that in commit H by whatever change you made. Its log message says what you want the log message to say, too.
But there's one thing that you don't like about commit K: it comes after commit H, when you'd like to have it come after commit J.
You can't change a commit
We noted near the top that no commit, once made, can ever change. Your existing commit K is set in stone: nobody, nothing, not even Git itself, can change anything about commit K. It comes after H and it has the snapshot and log message that it has, and that will be true forever.
But ... what if we could copy K to a new and improved commit? Let's call this new-and-improved commit K', to indicate that it's a copy of K, but with some things different.
What should be different? Well, we'd like it to come after J, for one thing. And then we'd like it to make the same change to J that K made to H. That is, if we ask what's different in the H-vs-K snapshots, and then ask what's different in the J-vs-K' snapshot we're about to make, we'd like to get the same changes.
There is a fairly low level Git command that copies exactly one commit like this, called git cherry-pick. This is in fact what we're going to end up using.
Still, we should talk here about git rebase. If we had a dozen, or a hundred, commits to copy, cherry-picking each one might be tedious; git rebase will automate the repeated cherry-picking, too. So rebase is the usual command to use.
Here's how rebase works:
- First, we have Git list out all the commits that it needs to copy. In this case that's just commit
K. - Then, we have Git check out (switch to) the commit where we want the copies to go. In this case that's commit
J. - Next, we have Git copy each commit, one at a time, from the list it made.
- Then we have Git take the branch name that found the last of the commits to copy, and move that name to point to the last-copied commit.
The end result of all of this, in this case, is:
K ???
/
...--G--H <-- main
\
I--J <-- br-B
\
K' <-- br-A (HEAD)
Note how commit K still exists. It's just that nobody can find it any more. The name br-A now finds the copy, commit K'.
Cherry-picking
This isn't what we want, so instead of using git rebase, let's use git cherry-pick. We will first run:
git switch br-B
to get:
K <-- br-A
/
...--G--H <-- main
\
I--J <-- br-B (HEAD)
Now we'll run:
git cherry-pick br-A
This uses the name br-A to find commit K, and then copies it to where we are now. That is, we get a new commit that makes the same changes that commit K makes, and has the same log message. This commit goes on the branch we're on now, so br-B gets updated to point to the copy:
K <-- br-A
/
...--G--H <-- main
\
I--J--K' <-- br-B (HEAD)
We should now inspect and test the new commit to make sure we really do like the result (because if we don't, there are a bunch more things you can do here). But assuming all goes well, now we'd like to discard commit K off the end of br-A.
We can't actually delete commit K. But a branch name simply holds the hash ID of the last commit that we want to say is "on the branch", and we can change the hash ID stored in a branch name.
Here things get slightly complicated, because Git has two different ways to do that. Which one to use depends on whether we've checked out that particular branch.
git reset
If we now run:
git switch br-A
to get:
K <-- br-A (HEAD)
/
...--G--H <-- main
\
I--J--K' <-- br-B
we can use git reset --hard to drop commit K off the end of the current branch. We simply find the hash ID of the previous commit, i.e., hash ID H. We can do this with git log, and then cut-and-paste the hash ID, or we can use some special syntax that Git has built in:
git reset --hard HEAD~
The syntax HEAD~ means: find the commit named by HEAD, then step back to its (first and only in this case) parent. That locates commit H, in this particular drawing.
The reset command then moves the branch name to point to this commit, and—because of the --hard—updates both our working tree and Git's index aka staging area to match:
K ???
/
...--G--H <-- br-A (HEAD), main
\
I--J--K' <-- br-B
Commit K no longer has a way to find it, so unless you tell them, nobody will ever know it was there.
Note that given this particular drawing, we could also have done git reset --hard main. The HEAD~1 style syntax works even in other cases, though.
git branch -f
If we don't first check out br-A, we can use git branch -f to force it back one step. This has the same kind of effect as git reset, but because we didn't check out the branch by name, we don't have to worry about our working tree and Git's index/staging-area:
git branch -f br-A br-A~
Here, we use the tilde suffix to the name br-A to have Git step back one first-parent hop. The effect is exactly the same, but we can only do this if we haven't checked out branch br-A.
A special case
Suppose that our drawings above aren't quite right. That is, suppose that instead of branches br-A and br-B pointing to different commits before we made commit K, they both pointed to the same commit. For instance, we might have had:
...--G--H <-- main
\
I--J <-- br-A (HEAD), br-B
If we were in this situation and then made commit K, we would get this:
...--G--H <-- main
\
I--J <-- br-B
\
K <-- br-A (HEAD)
Note that in this case, there is nothing we don't like about commit K: it has the right snapshot and it has the right metadata. The only problem is that the name br-A points to K, with br-B pointing to J. We'd like instead to have br-B pointing to K and br-A pointing to J.
We can get what we want by:
- moving the two branch names, or
- swapping the branch names
We can do the first one with a combination of git reset and git branch -f. We just have to be careful not to lose commit K's hash ID.
We can run git log and cut and paste K's hash ID, so that we don't lose it, and then run:
git reset --hard HEAD~
to get:
...--G--H <-- main
\
I--J <-- br-A (HEAD), br-B
\
K ???
Then we can run:
git branch -f br-B <hash-of-K>
pasting in the correct hash, to get:
...--G--H <-- main
\
I--J <-- br-A (HEAD)
\
K <-- br-B
for instance. Or, rather than taking that slightly risky method (what happens if we accidentally cut some other text and lose the hash ID?), we can update br-B first, with:
git branch -f br-B br-A
or:
git checkout br-B; git merge --ff-only br-A
(which introduces the --ff-only merge concept, which I'm not going to explain here) to get:
...--G--H <-- main
\
I--J
\
K <-- br-A, br-B
with one of those being the current branch. Then we can fix up br-A to move it back one hop.
最后，我們可以使用“重命名兩個分支”技巧。這需要選擇一個臨時使用的第三個名稱：
git branch -m temp # rename br-A to temp
git branch -m br-B br-A # rename br-B to br-A
git branch -m br-B # rename temp to br-B
在所有這些情況下，都不需要復制提交，因為K已經是正確的形式。我們只需要稍微調整一下名稱。
關鍵通常是繪制圖形
如果您對這些事情不確定，請繪制圖形。
您可以讓 Git 或其他一些程式為您繪制圖形：請參閱Pretty Git 分支圖。請注意，繪制和閱讀圖形需要一些練習，但這是一項重要的技能，在 Git 中。
繪制圖形后，您可以判斷是否需要新的和改進的提交（您可以使用這些提交，git cherry-pick也許）git rebase和/或您需要重新指向哪些分支名稱。
這也讓您深入了解我提到的警告。 當您將提交復制到新的和改進的提交時，任何已經擁有舊的和糟糕的1 的Git 存盤庫也需要更新。 所以，如果你已經使用git push到送舊，和糟糕的提交給其他一些Git倉庫，確保他們，誰“他們”，都愿意更新過。如果你不能讓他們切換，那么進行新的和改進的提交只會把重復提交弄得一團糟，因為即使你繼續洗掉它們，他們也會繼續把舊的和糟糕的提交放回去。因此，如果您發布了一些提交，請確保他們——無論“他們是誰”——同意切換到改進的提交，然后再進行變基或其他任何事情。
1如果某些東西是新的和改進的，那么舊版本會告訴你什么？或許這里的“爛”太強了，但至少讓人過目不忘。
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/363604.html
上一篇：Git子模塊更新卡在舊提交上