我们需要深入了解有关管理软件功能分支的分支和重新定位的最佳方法。我们有：
然后我们
当我们对开发进行更改时，我们是否应该将开发合并到功能A中，并将风险发送冲突给所有开发人员重新定义功能分支，或者我们应该将功能A重新定义为开发之外，然后为其计算机上的每个人生成相同的冲突再次（如果有的话）...
最好的方法是什么，还有另外一种，谢谢！
答案 0 :(得分：2)
听起来你在滥用功能分支。每个开发人员不应该拥有自己的每个功能分支的分支。正如您所发现的那样，过于复杂。这可能是因为你的功能太大了。
相反，每个功能都应该有一个功能分支。功能应该足够小，功能分支的寿命相当短，并且不需要进一步分支以进行长期的开发人员实验。功能完成后，分支不会被重用并被删除。
个别开发人员对某项功能的工作已由其本地存储库隔离。应该不鼓励习惯性的推动，开发人员只应在他们的工作准备好分享时才将他们的更改推送到功能部门。
根据经验，任何共享（即推送）的分支都不应该重新定位，否则会给下游的每个人带来问题。为简单起见，您应使用merge更新共享功能分支。但是，当该功能准备好合并时，您可以使用rebase来清理历史记录。
当然有例外。如果所有开发人员都熟悉rebased，那么共享分支可以重新定位。发送一条让每个人都知道已经发生了变种的消息通常是礼貌的，因此他们可以预期不可避免的pull错误。
答案 1 :(得分：-3)
查看github工作流程，而不是满足您的需求......
2关于这个问题的好消息来源：
https://guides.github.com/introduction/flow/
https://www.atlassian.com/git/tutorials/comparing-workflows/
并提出一个建议：你不应该将发布/共享的分支重新绑定到开发人员正在工作的分支上，除非在合并之前，以简化历史...