我们的团队有三名后端开发人员和两名前端开发人员。我们将Git用作版本控制系统，Jira用于问题和项目跟踪，Stash用作Git存储库。最后，我们使用SourceTree（git-flow}作为Git客户端。
问题在于我们的分支策略：我们正在使用Vincent Driessen的branching model。每个人都为每个问题创建feature branch，并在完成后将其合并回develop（通过拉取请求和对Stash进行审核后）。除此之外，我们为已完成但尚未发布的问题创建bugfix branches，为已发布的问题创建hotfix branches，为已完成的sprint创建release branches。在此方案中，没有人直接触及develop和/或master。我们的前端团队使用Sass作为CSS预处理器。最后，我们有TeamCity来构建更改，并在master分支上查找更改。
足够的背景故事，是吧？那么，问题就在这里：让我们说我们在sprint中有50个问题（我们每个人都有10个问题），并且在sprint结束时，客户端只想释放其中的35个（没有）需要问为什么，它是客户）。所以，我们需要以某种方式排除15个问题。大多数情况下，它们都是前端问题。由于我们的设置，此时所有内容都在develop分支上。我们现在有几种选择：
release branch创建develop并还原这15个问题（我们需要更新TeamCity，或者之后将此分支合并回master）。 master还原（在此方案中无需触及TeamCity）。 master（这可能会导致很多冲突）。但他们都有这个限制：Sass-to-CSS操作。如果我们选择第一个选项，并且遇到一些前端问题，肯定会发生冲突。如果我们选择第二个选项，我们就会失去对哪些内容的追踪，我认为这最终会被滥用。
这有一个重要的全局限制：我们需要在develop上进行测试（因此，每个完成的问题都需要在develop进行测试，这不能我们在master上发布了什么（在TeamCity中有改变这种情况的方法，但是没有人愿意改变它）。
问题是：如果同时有一些改进和停止，我们如何能够持续使用Git？
如果您需要，我可以提供更多详细信息，随时提出。
答案 0 :(得分：4)
希望我能很好地理解你的问题。我认为第四种解决方案对您的案例更有效：
develop和现在一样，把所有东西都放在那里，因为你必须在那里进行测试production（或release）分支 - ＆gt;这将是你的发布分支，至少目前是这样，直到你可以完全部署所有内容（如果你的客户想要那样）production分支中。基本上develop是您的qa分支（用于测试目的）。这比在sprint结束时挑选数十或数百次提交更好。所以我基本上建议的是在将功能分支合并到develop之后，不要删除它们，最后修复与该功能分支上的功能相关的错误修正，以及然后将分支合并到production。
如果您认为这种方法无法正常工作（除了您必须更改发布分支配置这一事实），请告诉我。