'git pull origin develop --rebase' 和 'git pull --rebase origin develop' 之间的区别

Question

我找不到不同之处，但可以有不同吗？之间：

Git docs 状态：

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

所以你会认为选项 B 是正确的，但是...

Answer 1

关于选项与参数的放置应该有多严格，存在着相互竞争的理论。 POSIX utility guidelines 规定了你所说的选项 B。Git，但是，即使有可选或必需的位置参数，也尽量灵活地放置选项。

这些是 Git 选项的一般规则：

位于git和sub-command动词之间的选项，例如git --no-replace-objects log，由Git 前端（git 程序本身）。前端将这些转换为环境变量设置，这意味着您始终可以设置一个环境变量。例如：
```
 git --git-dir=<path> ...
```
和
```
 GIT_DIR=<path> git ...
```
做同样的事情。

在 sub-command 动词之后的选项由 sub-command 处理。
Single-letter 选项，例如 -v，前面有一个连字符，可以组合在一起。 Multi-letter 选项（例如 --name-status）前面有一个双连字符。因此，在 git diff 中，有一个 -c 选项（“组合差异”），还有一个 --cc 选项（“密集组合差异”）； single-c 选项采用单破折号，double-c 选项采用双破折号。
任何以连字符开头的东西都是一个选项，在任何地方，除了在double-hyphen.
之后

git filter-branch 命令稍微打破了最后一条规则，因为它必须解析自己的选项，然后将一些选项传递给 git rev-list。所以对于 filter-branch，你运行:

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

和 <rev-list-options> 本身可以有选项，然后是第二个 stand-alone 双连字符 --，然后是路径名。¹

所有这些加起来就是您所说的选项 A。但是请注意，如果您在编写命令时考虑到选项 B，则它们都在选项 A 下工作。

and is there maybe an order by which the options are handled?

过去，对于某些 Git sub-command，有些地方的顺序特别重要。现在已修复，但您会在 the git checkout-index documentation:

中看到此备注

The order of the flags used to matter, but not anymore.

但是，通常情况下，选项会按照它们出现的顺序进行处理，并且重复的选项通常会覆盖之前的选项。例如：

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

使用 .git 作为 Git 目录，而不是 /tmp。

¹这里的可以，我的意思是身体上能够。你实际上不应该使用这种容量git filter-branch，因为它是一种将枪对准你自己脚的形式。

Difference between 'git pull origin develop --rebase' and 'git pull --rebase origin develop'