如果 A 且 B 正在使用相同的git repo而 A 会对功能分支进行更改：A-feature在 B 之前的回复中， B 现在需要做一个拉动才能推进。
但是这个描述的确切条件在哪里？例如。它是否适用于推送到回购的任何分支机构的任何变更？或者仅当 A 和 B 推送到同一分支时？意味着 B 可以推送到B-feature，即使 A 刚刚推到A-feature之前？
答案 0 :(得分：4)
意味着B可以推进B-feature，即使A只是在他面前推动A-feature？
是。只有当您推送到其他人更新的分支时，您才会收到警告：
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
hint: before pushing again.
git pull的唯一替代方法是git push --force（如果{{1}将覆盖A B发布的历史记录B推进A-feature，这很糟糕。）
请参阅＆＃34; git push --force, behind the scenes＆＃34;。
如果除B之外的任何人都在使用B-feature，那么当B想要将本地B-feature分支推送到上游回购时，就不需要拉动：推送将是快进的：你在远程分支上添加新的提交。
答案 1 :(得分：3)
在他（或她）将自己的更改推送到同一个分支之前，B需要引入A的更改的原因是否则B将重写历史记录（删除A的提交以支持他们自己的更改），以及A的提交（不属于B的本地分支）将丢失。
只有当你推到同一个分支时才会出现这种情况，所以是的，B可以推送到另一个分支而无需先提取A的提交。在这种情况下，A和B的提交合并将在以后合并它们的分支时进行。
如果您执行想要推送到远程分支，即使它包含不在您本地分支中的提交，您可以指示git不要警告您并继续使用推送，使用git push --force（或git push -f）。 但是，请注意，在大多数情况下（特别是当您与其他人一起工作时），建议不要这样做。不在您当地分支机构中的提交将从远程分支。
答案 2 :(得分：2)
Git中的每个分支都是按时间顺序提交的。
如果要推送不基于该分支的最新提交的提交，则需要先提取中间提交（可能涉及手动合并）。
当多个用户推送到同一分支时，这只是一个问题。当每个用户在个人分支上单独工作时，他们在推送之前永远不必拉。当然，除非他们故意想要合并其他人的分支。