我一直试图弄清楚如何做到这一点，但我所看到的答案都没有满足我想要的。
所以我们试图在git中使用自己的分支。我有分支me，当我运行git pull时，我想跟踪远程分支develop。然后，当我运行Git push时，我想要推送到me的遥控器，稍后将请求拉入develop我可以设置me以跟踪develop然后当我按下运行git push origin me或设置一个git宏但我想知道是否有办法设置我的配置，以便香草推/拉将做我想要的。
由于
答案 0 :(得分：2)
git中的默认拉取目标由本地分支的“上游”分支设置控制。如果您想从远程develop上的分支origin提取，请将上游设置为origin/develop：
$ git branch --set-upstream-to=origin/develop me
另一方面，默认推送目标由push.default配置参数控制。如果要推送到具有相同名称的远程分支，请将其设置为current（这至少是存储库范围，而不是分支范围）：
$ git config push.default current
了解更多：
$ git help branch
$ git help config
答案 1 :(得分：2)
更新 - 如评论中所述，有许多设置会影响我所讨论的三个映射中的每一个。我建议的组合将起作用（通过编辑来修复我从我的测试回购中复制refspecs时所犯的错误），但是它使得push的工作方式与现代默认设置略有不同。因此，您可能希望查看该特定设置的替代方案。
这里涉及一些配置选项，因此您可以灵活地执行您所要求的操作。实际上有三种映射：
当你获取时，你将远程引用（比如原来存在的develop）映射到本地仓库中的引用（比如origin/develop）。这由配置值remote.origin.fetch控制（默认情况下）。
当您拉动时，它首先进行提取（根据上述规则），然后决定要合并到当前分支的内容（您希望origin/develop合并到me）。这由配置值branch.me.merge控制（默认情况下）。
当您按下时，您将当前本地分支映射到特定引用以在远程上更新。通常可以使用某些默认逻辑来推断，但您可以使用remote.origin.push等配置值更具体地控制它。
请注意，我建议您不更改提取映射，因为origin/<branch>是您在遥控器上发生的事情的窗口，因此请将其与远程＆＃保持一致39; s分支名称最有意义。
所以要获得你想要的pull行为
git config branch.me.merge refs/heads/develop
现在push会认为事情看起来含糊不清，所以你要用
git config remote.origin.push refs/heads/*:refs/heads/*
答案 2 :(得分：1)
在我开始之前，我会在这里注意一件事：如果你跑：
git push origin me:me
然后下面没有与推送相关的东西。但这有点痛苦（参见＆＃34; B＆amp; D＆＃34;下面的说明）。
设置您必须跟踪任何其他参考的任何一个分支都很简单：只需使用git branch --set-upstream-to=<upstream> <branch>即可。但是你有另一个要求，这会产生一些问题。幸运的是，有一个使用push.default的解决方案。
这里的主要障碍是术语。 Git提供＆＃34;遥控器＆＃34; （实际上是本地事物），＆＃34;远程跟踪分支＆＃34; （也是本地的），--track标志git checkout（在本地设置一些东西），并使用动词＆＃34; track＆＃34; （这意味着不同于上述每一件事！）。这里的优点是，在Git中，所有都是本地的。一旦你保持自相矛盾的位置 - 遥控器和远程跟踪分支机构都是本地的，那么更多的事情是有道理的。只有当你将两个 Gits相互连接时，Git才能以任何其他方式工作，主要是使用git fetch或git push。这两个Gits然后在本地工作（当然！），但是互相提供数据，这样一个Git的项目就可以传递给其他人。
我们很快就会遇到第二个问题，但上面提到了问题：
我有分支
me，当我运行git pull时，我想跟踪远程分支开发......
这是您想要的地方：
git branch --set-upstream-to=origin/develop me
（假设您的遥控器被称为origin - 几乎总是如此）。这意味着＆＃34;将me的上游设置为origin/develop＆＃34;，这也是Git文档在具有动词＆＃34;跟踪＆ ＃34;，如＆＃34; me跟踪origin/develop＆＃34;。但如果我们这样做，我们很快就会遇到问题。
git pull本质上是运行git fetch（从其他Git获取内容），然后运行git merge或 - 如果你这样说 - {{1 }}。 （它运行一个故意限制的git rebase，它在大多数情况下几乎不会购买任何东西。无限git fetch现在可能会获得更多，但通过稍后取出来节省工作量。我通常建议每个人将其拆分为单独的git fetch和第二Git命令步骤，因为在我看来效果要清楚得多。但最后，这并没有太大的区别，除了给你更多的控制和可见性介于两者之间。）
git fetch步骤按照您提供的（本地）名称调用其他Git，通常为git fetch。然后另一个Git说＆＃34;我有一些像origin这样的分支，你想要这些提交吗？＆＃34;你的Git说＆＃34;是＆＃34;并下载提交。由于你的Git拥有拥有分支，你的Git然后重命名所有他们的分支：他们的develop成为你的远程跟踪分支{ {1}}。这使您的远程跟踪分支（同样是本地分支）与常规分支（也是本地分支）分开。
develop或（origin/develop）步骤使用您现在设置为git merge的远程跟踪分支与您刚刚获取的Git合并（或重新绑定）并放入你的git rebase。这就是我们想要设置上游的原因。但是等等......
然后当我运行Git push时，我想要推进
的遥控器origin/develop
此处我提到的问题就出现了。默认情况下，origin/develop（再次调用其他Git）＆＃34;想要＆＃34;向其他Git提供您的分支及其提交......然后让其他Git设置其同名分支。这是一个很好的默认，并且就在这里：你要求me的Git设置名为git push的分支，而不是它的分支名为origin。但是一旦我们设置了上游，我们就会更改默认。
现在你的Git将调用另一个Git，提供一些提交，然后......好吧，现在它变得复杂了。您的配置的一部分表示＆＃34;要求他们设置me＆＃34;，因为它是上游。您的配置的另一部分可能 - 这取决于设置和Git版本 - 告诉您的Git它应该仅要求他们更新他们的分支如果名称是develop 。显然这两个是不可能的。
develop 注意：如果您运行me，push.default 会被忽略。它只影响您忽略 git push remote refspec 部分的推送。
配置变量push.default有five possible settings（因为Git版本1.8左右）。自Git 2.0版以来，默认值为refspec。五个设置是：
push.default：错误输出。 simple或nothing失败了;它让你输入更多。您必须输入refspec。 （我称这是令人讨厌的束缚和纪律模式。我试了一段时间但是太烦人了。:-)）
git push：推送当前分支以更新接收端具有相同名称的分支。
git push origin：将当前分支推送到相应的上游分支。
current：推送当前分支以更新具有相同名称的分支，但如果您要推送到通常从中获取的位置，要求上游名称匹配
upstream：不关注当前分支;将与其他Git中的匹配分支名称一样多的分支。这部分是Git版本在2.0之前的历史性延续。如果您有分支simple，matching和a以及b，则其他Git具有分支c，me，{ {1}}，b和c，您的Git会要求他们的Git设置d和develop（这两个匹配的名称）。这种模式非常强大，在某些情况下非常方便，但它也有点危险，这就是为什么默认值在2.0中改变了。
如果仔细阅读该列表，您将看到（{可能）master设置所需的内容。这样，只要b说c，您的current（没有额外参数）就会：
git status以匹配您的on branch me。无论您的分支git push设置为其上游，都会发生这种情况。
请注意，如果您有两个遥控器，例如me和me，或me和origin，您仍然可以使用默认review设置。这是因为您的分支origin的上游为pull-request-host，而不是simple，而不是me。因此，两个名称匹配的特殊要求仅适用于origin/develop。当您转到review/*或pull-request-host/*时，origin会转回review，并尝试将pull-request-host推送到simple。