git - 一个很小的开发团队的GIT功能分支策略

我正在寻找有关在一个非常小的开发团队中使用版本控制的最佳实践的建议。我想知道我目前正在做的事情是否被视为良好做法。

基本上，我有一个master分支，该分支通常应该对生产代码稳定。我们有功能分支，代表正在开发的新功能。我的团队由两个开发人员组成：我是在Django中开发后端API的人，另一个是编写有角度的前端以使用此API的人。

我们当前要做的是创建一个功能分支，并为该功能构建API，而与此同时，前端人员将为该功能编写前端。我几乎总是完成并转到下一个功能，大多数时候，这需要我对上一个功能分支中的相同文件进行编辑。因此，当我完成第二个功能分支时，在第一个功能分支合并到master分支之后，几乎几乎总是发生合并冲突。

这些合并冲突通常很容易解决，但是感觉就像我们做错了什么。我想知道您如何看待我们的工作方式以及是否有人提出建议？

现在Long-lived feature branches（1）（2）被认为是反模式的（如您提到的冲突是缺陷之一）。

为避免这种情况，我建议您看一下Trunk Based Development：

一种源代码控制的分支模型，其中开发人员在称为“ trunk” *的单个分支中进行代码协作，通过采用有记载的技术来承受创建其他长期存在的开发分支的任何压力

尤其要注意Short Lived Branches部分（即：连续合并到主线）。

由于您将合并可能不完整的功能，因此您必须使用Feature Flags和Branch by Abstraction来切换此功能。