有几点疑问：
1、比如远程上有n个分支，我在pull的时候如何才能更新哪个分支的内容呢？
2、还是说n各分支都可以各自更新，最后汇总到master，我只需要pull master分支就好，但是这样会不会出现另一个问题，就是自己修改的文件，别人同时也在修改，这样再汇总master的时候就会有冲突，又如何知道谁的代码是最终的？
3、看到有教程说本地和远程master和a分支，在更新的时候先本地切换到a分支进行pull，再切换回本地master将最新的本地a分支合并过来，最后再push，那么为何要在本地保留两个分支呢？在我理解通过pull master:a取拉分支到本地master是否更方便？这样本地仅有一个分支
4、如3内容，merge合并分支到底在什么时候用？
感觉自己越用越乱了…还望解答，万分感谢！
1、比如远程上有n个分支，我在pull的时候如何才能更新哪个分支的内容呢？
你在 pull 的时候，如果你本地的当前分支和远端分支有关联，那就实际上等同于执行了 git fetch 和 git merge <remote>/<current_branch>，如果没有，就会有如下提示。
There is no tracking information for the current branch.
Please specify which branch you want to merge with.
See git-pull(1) for details.
git pull <remote> <branch>
If you wish to set tracking information for this branch you can do so with:
git branch --set-upstream-to=<remote>/<branch> bd2意思就是 git 当前不知道你这个分支应该与哪个远端分支进行关联，所以你需要使用以下步骤之一。
第一种，临时指定从哪个远端、分支拉取，每次都要填写 <remote> 和 <branch>
第二种，为当前本地仓库设这一个持久的上游和分支关联，这样以后每次都只需要 pull 就好了。
最简单的方式就是你要更新哪个分支，切换到哪个分支下，然后执行 pull，如果这是一个新的远端分支，比如同事刚刚推上去的，而你本地的这个分支也还没有关联远端分支，可能这时候你就无法 pull，那么简单的方式就是先 fetch，fetch 之后，会把远端的新分支拉下来，默认情况下，这时候，直接 switch 或者 checkout 切换到同事新推送的分支，他就会自动把这个远端分支关联到本地来。
还是说n各分支都可以各自更新，最后汇总到master，我只需要pull master分支就好，但是这样会不会出现另一个问题，就是自己修改的文件，别人同时也在修改，这样再汇总master的时候就会有冲突，又如何知道谁的代码是最终的？
2、这是常见的团队模型之一，所有人都从 master 创建开发分支，待开发、测试验证完成后，再把开发分支的代码合并到 master 上。
但是，如果两个人同时修改了一块地方，就可能会出现冲突，而这种情况，在一开始分配任务的时候就要尽量避免，总不能，一个人在开发功能，然后另一个人又在重构代码，这样必然会出现很多冲突。当然，除了这种极端情况，实际开发中还是会遇到冲突的，这时候就要两个人来确定应该怎么解决这块的冲突，应该保留谁的代码，或者都要保留。
3、看到有教程说本地和远程master和a分支，在更新的时候先本地切换到a分支进行pull，再切换回本地master将最新的本地a分支合并过来，最后再push，那么为何要在本地保留两个分支呢？在我理解通过pull master:a取拉分支到本地master是否更方便？这样本地仅有一个分支
实际工作中，master 或者其他主干分支，应该添加保护，不允许直接推送，只接受 PR 方式。
而不是任意一个人在本地把自己分支代码合并到 master 后就直接推新的上去。
master 和 a 在这里是两条不同的路线，一般的线路应该是 a 提交一个 PR 到 master，这时候可能会存在冲突，一般最简单的办法就是在你本地先切换到 master ，拉取一下最新的 master、再切换到 a ，也拉取一下最新的 a，现在 把 master 分支合并（merge 或者 rebase）到 a，并解决冲突，然后再把 a 推送到远端，现在 PR 上冲突已经解决了，就已经可以合并了，合并后，再回到你本地的 master，拉取最新的 master 代码，现在 master 就要已经包含了 a 的代码。
不要在意你本地多个分支，这是很常见的。
4、如3内容，merge 合并分支到底在什么时候用？
一般在本地用的比较多的就是要同步远端公共分支的最新修改。
比如你可以在开发过程中随时把远端公共分支，比如 master 的代码合并到你自己的开发分支来，以便于把别人已经合并到 master 的代码同步过来，当然，也可以最终 PR 的时候再执行。
其他场景就根据自己需要使用就好了。
补充回复：
原问 3 的实际操作是可行，但是团队协作里面公共分支一般都要设置保护，不允许推送。
第二步你 你 checkout 到 b 后，如果你本地没有这个分支，那这个时候实际上是对你刚刚 fetch 的远程分支再本地创建了一个同名分支，并且换关联了起来，这时候本地的 b 已经是你自 fetch 以后最新的了，可以不用再 pull，虽然再 pull 一下也没啥。，后面的步骤就是基本的分支合并流程，这主要取决于你要用来做什么，比如。
你先从 master 开了 feature-A 了做 A 需求，结果 A 还没做完，马上又来了一个优先的 B 需求，那你就要从 master 再拉一个 B，而不是在 A 上开始做 B 需求的内容，然后到后面，根据需要，可能有需要把 A 和 B 在下一个版本一起发布，那么你就需要从 master 或者 A、B 任意分支创建一个 feature-A+B 的分支，如果是基于 A 创建的，那你就 merge B，如果是基于 B 创建的，那就 merge A，如果是基于 master 创建的，那就要 merge A 和 B。
现在你的 feaute-A+B 分支就包含了 A 和 B 的代码，同时 原本的 A 和 B 也保留了，如果按照预期，你就可以用这个 feature-A+B 分支向 master 创建 PR，把代码合并进去。
但是，如果到了后面，发现 B 分支里面存在一些一时修复不了的 BUG，需要延期到下一个节点在合并到 master，那么此时你就可以直接从 feature-B 创建 PR 到 master 就好了。
所以，如果试想一下，最开始，B 需求进来的时候，你是在 A 分支继续开发的，遇到这种情况，你后面就不好解决了， 亦或者，你后面合并分支的时候，直接把 B 合并进 A 了，结果现在 B 又不发布了，也就不好处理。
所以，如果每到一个节点有分歧，来单独创建分支是最好的，而不是在一个分支上修修补补，当然，这主要说的是开发分支，主干分支一般都会保持稳定。
非常感谢您的解答！
关于问题3我可不可以这么理解，我的3实际操作可执行，但需要规避以免问题的发生？
问题1的回答对应具体操作是否为如下：
1、git fetch origin 拉取最新更新或者新建的分支，比如控制台返回了分支b；
2、git checkout b 将本地切换到分支b；
3、git pull origin b 更新本地b分支；
4、git checkout a 切换到自己的a分支；
5、git merge b 将b分支合并到自己的a分支；
6、git push a 最后将自己修改完后的最终代码上传到自己的远程a分支；
