更改提交，版本回退

• 1.get reset 重置HEAD指針的指向
• 2.git cherry-pick
• 3.git revert
• 4.git commit --amend修改提交
• 5.git rebase 變基提交
• • 5.1 git rebase --onto
  • 5.2rebase 產生沖突，解決沖突/終止變基
  • 5.3git rebase -i
• 6. rebase Vs merge

git 提供了【修改】【完善】版本庫中提交的機制。有很多需要讓你去修改或返工某個提交的情況，例如：在某個問題編程器遺留問題前修復它。
【注意事項】如果一個分支已經公開，就不應該重寫、修改、更改該分支的任何部分。應該使用git revert命令產生新的提交。

命令概覽

git reset commit_flag # --soft、--mixed、--hard 三個選項， 移動HEAD指向的提交git checkout branch1 # 轉移一個分支上的提交->另一個分支上 git cherry-pick commit_flag git revert commit_x # 撤銷某些內容，產生一個新的提交git checkout topic # 改變topic分支的基礎為master分支上的最新提交 git rebase master # 等價于git rebase master topicgit rebase --continue # 解決沖突后變基操作 git rebase --skip # 跳過某些會產生沖突提交，以避免某些沖突。 git rebase --abort # 可以終止變基礎操作，使版本庫恢復到變基前的狀態 git rebase -i [startpoint] [endpoint] # 和并多次提交并變基

git rebase -i合并多次提交

1.get reset 重置HEAD指針的指向

git reset 調整HEAD引用指向給定的提交，默認情況下會更新索引以匹配該提交。該命令的三個選項對應對HEAD、索引和工作目錄的影響記錄于下表。

git reset 命令將原來的HEAD存放在ORIG_HEAD 中。

選項HEAD索引工作目錄

git reset --soft	yes	no	no
git reset --mixed	yes	yes	no
git reset --hard	yes	yes	yes

git reset HEAD --廢棄最新提交的入庫狀態，可以重新編輯廢棄提交中新加的文件，添加全新文件，產生新的添加哦。
git reset --soft --僅僅調整提交消息，You can, but you don’t it. 提倡用git commit --amend.
git reset --hard --完全廢棄最新提交。改變工作目錄，原有的未保存修改將丟失，新文件被刪除 。

注意事項：如果將reset 命令應用在分支名上，會造成很多沒必要的問題。

2.git cherry-pick

[有趣的程序員，挑櫻桃呢]。

轉移一個提交：用于 將一個分支的 特定提交 引入 一個不同的分支中，常見用法是將 開發分支的提交 移植到 維護分支 上。

git checkout master # 需要引入新提交的目標分支 git cherry-pick commit-id1 # 在master 分支上新建一個提交，提交的內容是 commit-id1相對于commit_id0的新增內容【commit_id0 是 commit-id1 的上一個提交】 # 可能伴隨著解決沖突 # 沒有沖突的話，就會直接復用原有的提交信息，直接在當前分支上產生一個新的提交

轉移一批提交：另一個常見用途 用于重建一系列提交， 即從一個提分支中選一批提交，然后把他們引入新的提交中。

git checkout master git cherry-pick commit-id1..commit-id3

3.git revert

與git cherry-pick 命令作用相反：引用一個新的提交，消除給定提交的內容。（我想：git revert 無需解決沖突，但是如果某個提交基于需撤銷的提交，撤銷該提交后可能會出現問題）記得在提交日志中記錄相關的撤銷信息。

git revert commit_x

4.git commit --amend修改提交

當最新的提交 需要 小范圍的修改，可以使用git commit --amend 補救一下最新提交。 （其實它可以修改任意提交，但是一般情況下不推薦），對于普通git commit --amend 會彈出編輯會話，可在里面修改提交信息。

5.git rebase 變基提交

每一個在編輯的準提交都是基于某個父親提交進行的，可以改變準提交的基礎，即使用rebase操作。
一個常見的用途是–保持你正在開發的一系列提交相對于另一個分支(master)的最新提交進行的。

git checkout topic # 切換到topic分支, topic 分支是基于 master 分支的某個提交建立的 git rebase master # 變基礎操作， topic分支基于master分支的最新提交建立。 # 以上兩個命令等價于 git rebase master topic

5.1 git rebase --onto

一條分支上的開發線 整個 移植到不同的分支上

git rebase --onto master maint^ feature # feature分支基于maint^， 將feature 提交的基礎變為master分支。

5.2rebase 產生沖突，解決沖突/終止變基

變基操作一次只遷移一個提交，從原始提提交遷移到新的提交基礎。因此每個移動提交都可能產生沖突。

如果在rebase 的過程中發生了沖突，git 會自動掛起 rebase進程，當你手動解決沖突后，使用git rebase --continue命令恢復變基操作。

git rebase --continue命令提交解決沖突后的內容，繼續處理需要變基的下一個提交。

git rebase --skip 命令可以跳過某些提交，以避免某些沖突。但是這是非常不提倡的，產生的問題可能會像滾雪球一樣。

git rebase --abort 可以終止變基礎操作，使版本庫恢復到變基前的狀態（后面半句是否需要配合其他命令）

5.3git rebase -i

重新排序、編輯、刪除、把多個提交合并成一個、把一個提交分離成多個

git rebase -i master~3 # 會自動打開編輯器，編輯重新排序文件。 # 提交默認按照最老->最新的順序排列， 每個提交都有前都有一個pick, 放在最前面的提交將最先被拾起應用到目標分支 # 修改提交順序后，保存退出。 # squash 提交會合并的前一個提交中，（自動彈出）合并提交信息模版，是兩個提交信息的簡單合并

6. rebase Vs merge

把在branch1上的一系列提交rebase branch2的頭部 與 合并兩個分支 產生的效果是一致的，即在branch2 的新頭是兩個分支內容的組合。rebase 還是 merge 需要依據實際情況而言。具體技巧希望后續會說

要記住的重要概念：

變基礎操作會把提交重新線性化成新的提交。如果想要保留分支和合并結構需要使用

git rebase --preserve-merges master dev

不可達的舊提交會消失

如果有分支2基于 變基提交1，很有可能需要對2也進行相應的變基操作。

總結

以上是生活随笔為你收集整理的Git(11)-cherry-pick、reset、rebase的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。