假设有多个开发人员正在处理一个分支，称为TestBranch
现在，有两种(主要(方法可以让多个人在这个分支上工作。(也有变基，但我现在忽略了(
1：
- 开发人员进行更改
- 在他们推动之前，他们会通过
git pull origin TestBranch(或只是git pull(从其他人那里提取最新更改 - 处理任何合并冲突
git push origin TestBranch(或只是git push(，以便其他人都能进行更改
阿拉伯数字：
git checkout -b MyBranch(或先结账的分支机构(制作自己的个人分支机构来工作。- 当他们完成子任务时，他们会执行
git checkout TestBranch git pull获取TestBranch上的最新更改(不会触发任何合并，因为它们没有接触TestBranch，只是一个fast-forward(，git merge MyBranch- 处理任何合并冲突
git push origin TestBranch，以便其他人都能进行更改
第二种方法总体上需要更多的工作，但选项 #1 的 git 历史记录是一场噩梦，尤其是对于不止几个开发人员。这是一个纵横交错的线的巨大领域，大量不是实际内容的节点，等等。
我该如何解释？有没有一个很好的例子，也许是一张图片，有什么可以说为什么从长远来看做#1是一个坏主意？
(或者如果我错了，请随时告诉我(
首先，以下是我的个人观点，我从经验中知道，讨论 git 工作流程可能是一个非常激烈的话题，因为有些决定取决于口味。
但是，已经有一些(非常常见的(分支策略(工作流(来处理这个问题和其他问题。Atlassian 对一些模型有很好的概述。
对于您的特定问题，如果您想拥有一个干净的 git 历史记录并且只在一个分支上工作，您是否想过在git push之前做git pull --rebase(假设您正在处理TestBranch(？这将为您提供一个"漂亮"且直接的提交历史记录，而不会引入任何开销(无论如何都需要修复合并冲突(
如果人们处理特定的块(比如新功能或错误修复(，引入"功能"或"修复"分支通常是个好主意，类似于你在(2(中建议的。这也为提交增加了一个很好的范围，所以当分支有一个明确的名称(比如feature/tooltip(时，你立即知道在哪里寻找该功能的更改。与您的建议的不同之处在于，分支的范围不是由处理它的用户决定的，而是由它包含的功能/修复来限定的。因此，这可能会导致多个(但通常很少，因为这些分支应该是短暂的(开发人员在一个分支上工作。
另外，如果我正确理解您的两种方法，这两种方法都会创建相同数量的合并冲突和分支，因此我看不到 (2( 中的改进。