你需要先玩一下VCS，有些问题会自己解决。例如，分支包含了整个项目的源代码以及一些额外的更改。它们不能只包含更改。
特征分支的使用有几种方式，更容易说的是哪些特征分支不是：

• 它们不是发布或热修复分支，人们可以在其中保存特定发布的更改
• 它们不是一个development分支，当人们想分离出两个主要分支时，有时会保留这种分支-一个包含最新的稳定版本，一个包含当前的开发（不一定是稳定的）。
• 它们不是 Backbone.js （也称为master、main）。此分支可以与development相同的方式使用，也可以是“最新稳定”分支。

除非我忘记了什么，其余的都是特性分支。2个主要的使用方法：
1.引入一个新特性。在这种情况下，这样的分支可以包含相当多的变化。
1.实现一个特性的一部分或者任何类型的改变（可能是一个微小的改变）。虽然我们称之为特性分支看起来很傻，但我们坚持使用这个名字。创建这样的分支是为了暂时隐藏改变和/或出于技术原因-能够创建代码评审（使用拉/合并请求）
这些天，由于持续集成是趋势，我们应该使用方法#2。我们不喜欢保持长期运行的分支。查看“基于 Backbone.js 的开发”了解更多细节。
PS：你会经常遇到GitFlow，因为它曾经是一个流行的方法。它不是一个过时的和过于复杂的策略，不应该再使用了（实际上它总是违背持续集成的原则，但人们不知道它：））。Even its author doesn't recommend it anymore。PPS：在基于 Backbone.js 的开发中，如果使用Gerrit的微代码评审，我们可以完全取消特性分支，而不是使用GitHub、GitLab和其他工具创建拉取/合并请求。

我将把这个放在这里，但是这个问题很可能会被认为是固执己见的。这里有一个完整的软件开发生命周期需要理解。
feature分支的概念是gitflow工作流的一部分。
https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
假设你有一堆项目，每个项目都有一个Jira或类似程序中的票证。每个票证概述了你项目的一个功能。该功能可以是一个小更改或一个大更改。一个大票证（Epic）可能会分解为一组较小的票证。
因此，对于每个票证，您创建一个feature分支。如果票证是PRJ-1234，则从develop或main分支（取决于您的流程）创建一个新分支。将该分支命名为feature/PRJ-1234。
您可以从feature分支创建一个拉取请求。请对其进行审核，然后将其合并到您的develop分支。您可以在开发期间继续使用该功能分支来解决bug。一旦该代码被合并并准备部署到生产中，您可以删除该feature分支，因为该代码现在是主代码库的一部分。
所以如果你有8个ticket，那么开发团队应该有8个feature分支，这些分支应该只存在于sprint（发布）的生命周期中，你不能为其他ticket重用feature分支。