我们两个人在做某事。我们正在使用这种分支结构
- 主
- dev-A
- dev-B
我们俩都在单独的分支（dev-A，b）上工作，并且每当完成时-我们将更改推广到master。
但是这样做的缺点是我们无法获得其他开发人员所做的更改。一切都存在于主树中-但是我们无法获得其他开发人员所做的最新更新。
有没有办法解决这个问题，还是我们应该更改分支结构（按功能）？
我们两个人在做某事。我们正在使用这种分支结构
我们俩都在单独的分支（dev-A，b）上工作，并且每当完成时-我们将更改推广到master。
但是这样做的缺点是我们无法获得其他开发人员所做的更改。一切都存在于主树中-但是我们无法获得其他开发人员所做的最新更新。
有没有办法解决这个问题，还是我们应该更改分支结构（按功能）？
Answers:
我已经看到了在两种主要情况下使用的开发人员分支：
开源社区，这些分支实际上是存储库的分支，因此项目维护人员可以锁定对主存储库的访问，并需要通过拉取请求进行集成。这使贡献者的生活更加困难，但对于维护人员而言却更加容易，这当然是关键所在，并且这是GitHub上非常成功的模型。
团队和组织没有持续的集成，并且没有部署不稳定的记录，更糟的是其构建不稳定的记录。这些团队通常尝试使用开发人员分支来保护主线的稳定性，结果通常是，发布之前漫长而痛苦的合并期，然后是更长而痛苦的稳定期，有时直到发布后才会发生。
我不希望这成为为什么需要CI的恼，但从您的问题中可以很明显地看出，您知道自己没有足够频繁地集成更改，因此IMO没有必要围绕这个问题进行讨论。
除非您实际上是在一个地理上分散的团队中工作，并且需要“控制”外部开发人员的更改，否则每个开发人员的分支机构的模式实际上没有多大意义。对于git来说，这尤其没有意义，因为从技术上来说，每个开发人员都已经拥有自己的存储库。大多数组织应该非常频繁地进行集成-例如每天进行几次。
我目前是由35个贡献者组成的小组的一部分，该贡献者分为4个独立的团队，大多数人每天至少检查2-3次，有些人检查10-15次；看到建筑物损坏是很不寻常的，而让它们停留几分钟以上的情况极为罕见。大多数时候，Git毫不费力地处理合并，以至于远程开发人员分支只是不必要的开销。只需在推送之前进行拉取，本地合并和运行提交测试，这很简单。
如果您绝对必须推迟集成以保护主分支的稳定性，那么典型的，经过验证的模型是使用不稳定的分支 -有时称为开发分支，如成功的Git分支模型中所述。如果开发人员至少每天至少不能一次成功地合并到该分支中（该分支仅需要构建，就可以正常运行），那么您将遇到质量/学科问题，而不是版本控制问题；通过使用非集成的开发人员分支掩盖它只能解决该问题，并且这样做实际上使最终合并比实际需要的更加痛苦和不稳定。
功能分支并不是最坏的情况，但是IMO很少有足够大的项目来保证它们。如果您的项目非常大（即同时处理大量功能），则将其拆分为单独的自治组件将获得比记录源代码控制问题更好的结果。
如果需要，您可以忽略此建议，很多团队也可以这样做，但是上面链接的分支模型如此流行和成功的原因之一是，该模型旨在与持续集成一起工作，而不是与之相反。
在工作分支中，如果要执行以下操作：
git commit -am "Committing changes before merge"
git merge master
您也可以从其他开发人员分支合并
git checkout dev-A
git merge dev-B
git merge master在签出功能分支时，我一直在寻找。谢谢