“git pull origin develop --rebase”和“git pull --rebase origin develop”之間的區別

Question

我找不到區別，但可能有區別嗎？ 之間：

Git文檔狀態：

git pull [<options>] [<repository> [<refspec>…]]

所以你會認為選項 B 是正確的，但比..

Answer 1

關於選項與論點的放置應該有多嚴格，存在相互競爭的理論。 POSIX 實用程序指南規定了您所說的選項 B。然而，Git 嘗試在選項放置方面非常靈活，即使存在可選或必需的位置參數。

這些是 Git 選項的一般規則：

git和子命令動詞之間的選項，例如git --no-replace-objects log ，由 Git 前端（ git程序本身）處理。 前端將這些轉換為環境變量設置，這意味着您始終可以設置一個環境變量。 例如：
```
 git --git-dir=<path> ...
```
和
```
 GIT_DIR=<path> git ...
```
做同樣的事。
放置在子命令動詞之后的選項由子命令處理。
單字母選項（例如-v ）前面有一個連字符，可以組合在一起。 多字母選項，例如--name-status ，前面有雙連字符。 因此，在git diff ，有一個-c選項（“組合差異”），但也有一個--cc選項（“密集組合差異”）； single-c 選項需要一個破折號，double-c 選項需要一個雙破折號。
任何以連字符開頭的東西都是一個選項，除了雙連字符之后。

git filter-branch命令稍微打破了最后一條規則，因為它必須解析自己的選項，然后將一些選項傳遞給git rev-list 。 因此，使用 filter-branch，您可以運行：

git filter-branch <filter-options> -- <rev-list-options>

並且<rev-list-options>本身可以有選項，然后是第二個獨立的雙連字符-- ，然后是路徑名。 ¹

這一切加起來就是你所說的選項 A。但請注意，如果你在編寫命令時考慮到選項 B，它們都在選項 A 下工作。

是否有處理選項的順序？

過去，對於某些 Git 子命令，有些地方的順序特別重要。 現在已修復，但您將在git checkout-index文檔中看到此評論：

標志的順序曾經很重要，但不再重要。

然而，一般來說，選項是按照它們出現的順序進行處理的，而且經常重復的選項會覆蓋前一個選項。 例如：

git --git-dir=/tmp --git-dir=.git status

使用.git作為 Git 目錄，而不是/tmp 。

¹到可以在這里，我的意思是身體能。 您實際上不應該將這種容量與git filter-branch因為它是一種將槍對准您自己腳的形式。