Git 分叉工作流程，遥控器的名称是什么？
Git forking workflow, what names for the remotes?
我可以为本地存储库中定义的遥控器选择任何名称。无论偏好和意见如何：我应该选择什么名称，才能最好地使用工具默认值？
将 Git 与 forking workflow for collaboration 结合使用是一种流行且有用的模型。
该工作流程意味着我有：
- 本地存储库，我通常在其中执行所有 Git 操作。
- 中央存储库，每个人都可以从中提取更改。
- 个人分支存储库，只有我将更改推送到其中。
本地存储库需要知道作为远程的中央存储库，因为“这是更改的来源以及我需要从中合并的内容”。如文章所述：
[…] other developers should pull from the official repository to
synchronize their local repositories.
本地仓库需要知道作为远程的个人分叉仓库，因为“这里是这些本地更改将被推送到的地方，默认的本地分支应该发布到这里”。如文章所述：
[the developer will] push the commit to their own public
repository — not the [central] one. Then, they file a pull request
with the [central] repository, which lets the project maintainer know
that an update is ready to be integrated.
所以有一个三角工作流程：更改首先在我的本地存储库中提交，然后推送到 public 个人存储库，然后合并到中央存储库，然后返回到我（和其他人的）本地存储库.
两个遥控器，都是主遥控器
Git 工具生态系统倾向于假设我的本地存储库只有一个规范远程，名为“origin”。但是有两个强有力的候选者：已发布的个人分支存储库和中央存储库。
当然，我可以为遥控器选择任何我喜欢的名字；我不受那个选择的限制。我想问的是什么名称可以 使使用标准工具 和 Git 的生活更轻松？
工具有默认值和假设；我正在尝试找到一组名称，这些名称将使我（因为工具的假设倾向于正确选择）和我的队友（通过让每个人都用相同的名称谈论遥控器）的生活更轻松。
我应该为这两个遥控器选择什么名称，哪些工具仍需要告知这些名称以进行常见操作？我不是在寻找意见；我正在寻找关于什么 最有效 的指导。
说到triangular workflow，那么远程命名规范就简单了：
origin 为你的分叉，为推动upstream 用于原始 repo，用于拉取
您可以在“How to fork a new branch from a repo when you already have the master?”中查看示例
并且您可以配置您的分支 to pull from upstream, but push to origin。
OP 的回答过度考虑了这些术语的含义。
答案更简单：origin 是 默认 远程名称，这意味着如果您不指定来源（在 git push例如命令）origin 将被推断（除非为该分支设置了 branch.<name>.remote 或 branch.<name>.pushRemote）
问题就变成了：在三角工作流中，你默认推到哪里？ origin。你的只有小学。 （以及名称 Git tools expect）。
如果您从不同的位置推送，您也可以从中完美地获取一个遥控器。
Upstream 只是为了让您自己的回购（本地和原始）与新提交保持同步。它可以是任何其他名称（对于任何 Git 工具都无关紧要）
它不是“默认上游存储库”。你只是偶尔在需要的时候追踪上游。
约定在Atlassian article on the “forking workflow”中描述：
[…] the Forking Workflow requires two remotes—one for the official repository, and one for the developer’s personal server-side repository. While you can call these remotes anything you want, a common convention is to use origin as the remote for your forked repository […] and upstream for the official repository.
所以三角工作流的约定是：
origin 远程定义本地分支的推送目的地，在此工作流中是 public 个人分支存储库。
upstream 远程定义本地存储库跟踪的“默认上游存储库”，将从中获取更新。
Git 文档在这个问题上基本上是混淆的。它的 glossary definition of origin 表示：
origin
The default upstream repository. Most projects have at least one upstream project which they track. By default origin is used for that purpose. New upstream updates will be fetched into remote-tracking branches named origin/name-of-upstream-branch […]
该定义——以及名称“origin”的自然英语含义——强烈暗示 origin 远程应该是中央的、权威的、规范的上游存储库，从中获取新的更新。
所以文档中的定义，以及单词的自然含义，不符合约定：没有从origin获取上游更改，这与 Git 文档中 origin 的概念相矛盾。 Git 文档定义为 origin 的实际上是约定中的 upstream。
我可以为本地存储库中定义的遥控器选择任何名称。无论偏好和意见如何：我应该选择什么名称，才能最好地使用工具默认值？
将 Git 与 forking workflow for collaboration 结合使用是一种流行且有用的模型。
该工作流程意味着我有：
- 本地存储库，我通常在其中执行所有 Git 操作。
- 中央存储库，每个人都可以从中提取更改。
- 个人分支存储库，只有我将更改推送到其中。
本地存储库需要知道作为远程的中央存储库，因为“这是更改的来源以及我需要从中合并的内容”。如文章所述：
[…] other developers should pull from the official repository to synchronize their local repositories.
本地仓库需要知道作为远程的个人分叉仓库，因为“这里是这些本地更改将被推送到的地方，默认的本地分支应该发布到这里”。如文章所述：
[the developer will] push the commit to their own public repository — not the [central] one. Then, they file a pull request with the [central] repository, which lets the project maintainer know that an update is ready to be integrated.
所以有一个三角工作流程：更改首先在我的本地存储库中提交，然后推送到 public 个人存储库，然后合并到中央存储库，然后返回到我（和其他人的）本地存储库.
两个遥控器，都是主遥控器
Git 工具生态系统倾向于假设我的本地存储库只有一个规范远程，名为“origin”。但是有两个强有力的候选者：已发布的个人分支存储库和中央存储库。
当然，我可以为遥控器选择任何我喜欢的名字；我不受那个选择的限制。我想问的是什么名称可以 使使用标准工具 和 Git 的生活更轻松？
工具有默认值和假设；我正在尝试找到一组名称，这些名称将使我（因为工具的假设倾向于正确选择）和我的队友（通过让每个人都用相同的名称谈论遥控器）的生活更轻松。
我应该为这两个遥控器选择什么名称，哪些工具仍需要告知这些名称以进行常见操作？我不是在寻找意见；我正在寻找关于什么 最有效 的指导。
说到triangular workflow，那么远程命名规范就简单了：
origin为你的分叉，为推动upstream用于原始 repo，用于拉取
您可以在“How to fork a new branch from a repo when you already have the master?”中查看示例
并且您可以配置您的分支 to pull from upstream, but push to origin。
OP 的回答过度考虑了这些术语的含义。
答案更简单：origin 是 默认 远程名称，这意味着如果您不指定来源（在 git push例如命令）origin 将被推断（除非为该分支设置了 branch.<name>.remote 或 branch.<name>.pushRemote）
问题就变成了：在三角工作流中，你默认推到哪里？ origin。你的只有小学。 （以及名称 Git tools expect）。
如果您从不同的位置推送，您也可以从中完美地获取一个遥控器。
Upstream 只是为了让您自己的回购（本地和原始）与新提交保持同步。它可以是任何其他名称（对于任何 Git 工具都无关紧要）
它不是“默认上游存储库”。你只是偶尔在需要的时候追踪上游。
约定在Atlassian article on the “forking workflow”中描述：
[…] the Forking Workflow requires two remotes—one for the official repository, and one for the developer’s personal server-side repository. While you can call these remotes anything you want, a common convention is to use
originas the remote for your forked repository […] andupstreamfor the official repository.
所以三角工作流的约定是：
origin远程定义本地分支的推送目的地，在此工作流中是 public 个人分支存储库。upstream远程定义本地存储库跟踪的“默认上游存储库”，将从中获取更新。
Git 文档在这个问题上基本上是混淆的。它的 glossary definition of origin 表示：
origin
The default upstream repository. Most projects have at least one upstream project which they track. By default
originis used for that purpose. New upstream updates will be fetched into remote-tracking branches namedorigin/name-of-upstream-branch[…]
该定义——以及名称“origin”的自然英语含义——强烈暗示 origin 远程应该是中央的、权威的、规范的上游存储库，从中获取新的更新。
所以文档中的定义，以及单词的自然含义，不符合约定：没有从origin获取上游更改，这与 Git 文档中 origin 的概念相矛盾。 Git 文档定义为 origin 的实际上是约定中的 upstream。