假设我们有一个远程存储库，我们在本地克隆它。
我们结帐了 master 分支，现在我们有了本地 master 和远程 remotes/origin/master
然后，我必须创建一个新的主题分支，该分支将在审核后合并到远程主分部中：
从本地 master 与远程等效广告（如果有任何差异）分支的优缺点是什么？
相同的参数是否适用于长时间运行的分支？
修改
我一直在尝试跟踪本地分支机构的 origin/master ，我注意到一个很大的缺点：在TFS上它不会让你创建一个拉取请求。如果你想要一个，你需要将你的分支推送到原点，这将把它从master分离，它将跟踪新的远程分支，然后创建一个pull请求;我所说的有什么不对吗？如果没有，那么这是不从 origin/master 分支的重要原因。
答案 0 :(得分：1)
只要本地主分支与远程分支是最新的，就没有区别。两者都将处于提交/时间点，因此无论你从哪一个开始都无关紧要。
但是，如果您对主分支进行了本地更改，但无法保证将其合并到新分支合并到的远程分支中，则可能需要从远程引用开始。在这种情况下，两者之间存在差异，因为两个分支包含不同的提交。
通常，规则是从最后要合并的分支开始分支。如果你跟踪远程分支机构1对1本地与远程分支将没有区别。
答案 1 :(得分：1)
假设master与其远程跟踪分支origin/master保持同步，则根本没有实际差异。
分支只是历史记录中提交的指针，因此当分支一个分支时，您只是创建指向同一目标的另一个指针。该指针与“原始指针/分支”无关;它只指向一个提交。因此，当您继续处理该新分支时，新提交将仅使用提交的父关系引用基础。分支机构本身与历史完全无关。
Git有办法向分支添加某种元数据。但是，标准的分支机制，例如，使用git branch或git checkout -b，不会让Git将任何其他元数据附加到分支机构。
唯一相关的元数据是远程跟踪分支。但通常情况下，您不希望有多个分支跟踪同一个上游分支。
因此，在您的情况下，当您创建要素分支时，只需分支master或origin/master。这并不重要。
答案 2 :(得分：1)
运行git fetch将始终使origin/master保持最新状态，因此在大多数环境中，首选origin/master可能是正确的。当我为所有开发使用主题分支时，我发现本地master很烦人，因为我觉得有必要不时更新它，即使它没用，所以我更喜欢删除它。
选择本地master作为开发基础的一个可能原因是您可以更好地控制它。如果有人向远程master推送错误的力量，当您尝试将其合并到本地master时，您可能会注意到它，而origin/master只会自动指向新的历史记录。或者您可能想要一个稳定的开发基础，同时仍然可以获取上游更改？
答案 3 :(得分：0)
我认为没有任何绝对的利弊。您只是从一个分支或另一个分支开始。本地主服务器是PC上的主分支。远程主服务器只是远程PC（服务器等）上的主分支。它们都只是它们所在机器的本地分支，它们具有相同的名称。
唯一的区别是远程行为作为跨多个用户的中心。我强调行为，因为git中没有任何东西强迫远程分支成为“中心”。它恰好被您的团队用作会议的中心。
可能存在一些微妙的优点，例如您可以通过从一个或另一个分支来隐式设置上游分支。或者，您无需担心本地主分支机构不能通过直接从远程分支来完成与远程数据库的完全同步。
考虑到所有这些，我甚至不确定如何基于远程分支而不是本地分支来分离分支......但假设可以完成，上面应该是准确的=）。
答案 4 :(得分：0)
没有区别，通常如果你想创建一个新的分支，例如Branch1，你将从git服务器在系统中本地检查主服务器的最新提交，结帐主代码到名为Branch1的新本地分支，并将Branch1推送到提交后的git服务器。这里的要点是确保您拥有最新的主代码。