[英]What's the difference between git checkout <remote>/<branch> vs git checkout <branch>?
[英]What's the difference between git switch and git checkout <branch>
Git 2.23 引入了一個新命令git switch
- 閱讀文檔后,它似乎與git checkout <branchname>
可以解釋一下區別嗎?
引入了兩個新命令“git switch”和“git restore”來拆分“簽出分支以推進其歷史”和“簽出索引和/或樹狀路徑以推進當前歷史”從單個“git checkout”命令中提取出來。
好吧,根據您鏈接到的文檔,其唯一目的是拆分和闡明git checkout
的兩種不同用途:
git switch
現在可以用於更改分支,就像git checkout <branchname>
一樣git restore
可用於將文件重置為某些版本,就像git checkout --<path_to_file>
一樣人們對這些使用git checkout
的不同方式感到困惑,正如您可以從 Stackoverflow 上有關git checkout
的許多問題中看到的那樣。 Git 開發人員似乎已經考慮到了這一點。
git checkout
有點像瑞士軍刀,有幾個不相關的用途。
如果您修改了文件但沒有暫存更改,那么git checkout <filename>
將撤消修改...取消對文件的更改的快速簡便的方法。 你留在同一個分支。
git checkout <branchname>
(如您所述)切換分支。
兩個完全不同的目的,如果文件名和分支名相似,可能會導致混淆。
將它作為兩個命令更清楚。
正如您在引用的 2.23.0 發行說明部分中所述,引入了switch
和restore
命令以將checkout
命令拆分為兩個單獨的部分:
換句話說, checkout
是在做兩件不同的事情,而這個版本將這些不同的事情中的每一個都分解成自己的重點命令。
checkout
的雙重目的可以在文檔中的摘要描述中看到:
git-checkout - 切換分支或恢復工作樹文件
添加了switch
命令的提交的提交消息解釋了原因:
“git checkout”做太多事情是許多用戶困惑的根源(有時它甚至會咬舊計時器)。 為了解決這個問題,該命令將分為兩個新命令:切換和恢復。 舊的“git checkout”命令仍然存在,直到所有(或大多數用戶)都厭倦了它。
由此可見,引入新命令是為了通過兩個集中命令而不是一個多用途命令來減少混亂。
請注意,截至 2021 年 12 月,新命令仍列為實驗性命令( switch
、 restore
):
此命令是實驗性的。 行為可能會改變。
我還沒有在任何地方找到命令的完整比較。 通過閱讀文檔,我認為這應該是一個相當完整的比較:
上一個命令 | 新命令 |
---|---|
git checkout <branch> |
git switch <branch> |
git checkout |
不適用(使用git status ) |
git checkout -b <new_branch> [<start_point>] |
git switch -c <new-branch> [<start-point>] |
git checkout -B <new_branch> [<start_point>] |
git switch -C <new-branch> [<start-point>] |
git checkout --orphan <new_branch> |
git switch --orphan <new-branch> |
git checkout --orphan <new_branch> <start_point> |
不適用(使用git switch <start-point> 然后git switch --orphan <new-branch> ) |
git checkout [--detach] <commit> |
git switch --detach <commit> |
git checkout --detach [<branch>] |
git switch --detach [<branch>] |
git checkout [--] <pathspec>… |
git restore [--] <pathspec>… |
git checkout --pathspec-from-file=<file> |
git restore --pathspec-from-file=<file> |
git checkout <tree-ish> [--] <pathspec>… |
git restore -s <tree> [--] <pathspec>… |
git checkout <tree-ish> --pathspec-from-file=<file> |
git restore -s <tree> --pathspec-from-file=<file> |
git checkout -p [<tree-ish>] [--] [<pathspec>…] |
git restore -p [-s <tree>] [--] [<pathspec>…] |
如該比較所示,通過將舊命令名稱 ( checkout
) 替換為新命令名稱 ( switch
、 restore
),可以將一些先前的用法簡單地轉換為新命令,而其他用法則需要額外調整。 顯着的變化包括:
-b
/ -B
選項重命名為-c
/ -C
--detach
現在在切換到分離的頭部時總是需要的,以前它對於提交是可選的,但對於分支是必需的-s
選項給出,而不是作為內聯參數 switch
有一些限制:目前您可以從任何提交切換到<branch name>
,但是不可能從<branch name>
切換到狀態為detached HEAD的特定提交。 因此,您需要使用git checkout 5efb
(其中 5efb 是對任意提交的哈希引用的示例)
這是 git 手冊的摘錄——man man git-switch
。
概要
git switch [<options>] [--no-guess] <branch> git switch [<options>] --detach [<start-point>] git switch [<options>] (-c|-C) <new-branch> [<start-point>] git switch [<options>] --orphan <new-branch>
描述
切換到指定分支。 更新工作樹和索引以匹配分支。 所有新的提交都會被添加到這個分支的頂端。
可選地,可以使用
-c
、-C
自動從同名的遠程分支創建一個新分支(參見--guess
),或者使用--detach
將工作樹從任何分支中分離,並進行切換。切換分支不需要干凈的索引和工作樹(即與
HEAD
相比沒有區別)。 但是,如果操作導致本地更改丟失,則操作將中止,除非使用--discard-changes
或--merge
另有說明。此命令是實驗性的。 行為可能會改變。
tl;dr:當使用checkout
和--force
時,您可以在合並過程中切換分支。 你不能用switch
做到這一點。
細節:
其他答案已經涵蓋了將checkout
拆分為switch
和restore
的動機,以及存在語法使用差異的事實。 (例如,您可以直接將checkout
與 commit 或遠程跟蹤分支(如origin/main
)一起使用,但使用switch
,您還必須明確指定--detach
選項。)但是,我也發現了至少一個顯着的功能差異。
git switch -f
記錄如下:
即使索引或工作樹與
HEAD
不同,也要繼續。 恢復索引和工作樹以匹配切換目標。 如果指定了--recurse-submodules
,則子模塊內容也會恢復以匹配切換目標。 這用於丟棄本地更改。
同樣, git checkout -f
被記錄為這樣(強調最后一句話):
切換分支時,即使索引或工作樹與
HEAD
不同,即使途中有未跟蹤的文件,也要繼續。 這用於丟棄本地更改和任何未跟蹤的文件或目錄。從索引中檢出路徑時,不要在未合並的條目上失敗; 相反,未合並的條目將被忽略。
似乎最后一句話適用於checkout
的其他含義,即等效的restore
命令。 但是,當您當前正處於合並中間時嘗試切換分支時, git checkout -f
將成功,即使您當時有未解決的沖突。 如果您當前正在合並(即使沒有沖突), git switch -f
根本不起作用,因為您收到以下錯誤消息:
致命:合並時無法切換分支
注意:此差異是使用 Git 版本 2.37.1 測試的
你會得到不同的效果。 當你結帳時,你會得到你結帳的分支的文件。 如果您切換分支更改但文件沒有更改。 如果您提交,則提交將轉到該分支。 如果您正在編輯但簽出,則文件將重置為簽出的文件狀態,可能會丟失工作或獲得所需的還原。
聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.