我读了很多文章，但这对我来说还不清楚。假设我有两个分支的项目：master和dev。 Dev拥有开发分支并掌握稳定分支 - 代码已准备好发布。
问题1：
我想为dev分支添加一些功能 - 所以我创建了另一个基于dev的分支 - 让我们称之为：Feature / 1 / Some-feature-description，这个功能很大，所以我把它分成三个不同的branches：Feature / 1.1 / Some-sub-feature-description，Feature / 1.2 / Some-sub-feature-description and Feature / 1.3 / Some-sub-feature-description
所以我开始研究功能1.1，我编写了一些代码，在这样做的过程中，我发现了一个错误（与子功能1.1或主要功能1没有直接关系），我该怎么办？我看到几种可能的解决方案：
切换回我的dev分支，创建另一个分支（Fix / 1 / Some-fix-description），修复问题，将Fix分支合并到dev分支，切换到Feature 1（主要功能分支）合并从dev更改，切换到子功能1.1合并来自开发的更改。
修复功能1.1中的问题（或者可能创建另一个基于功能1.1的修复分支，修复问题并将其合并回功能1.1分支），当功能完成时 - 将其与大功能1合并分支，完成后，将其与开发合并。
在单个和多个开发人员项目中，哪种方法（更好）是正确的？也许还有另一种我不知道的方式？
问题2：
在我将Feature / 1.1 / branch与Feature / 1 /合并后，我在Feature / 1.1 /代码中发现了一个错误，或者我只想在那里进行一些更改 - 是否可以切换回Feature /1.1/，合并当前的Feature / 1 / branch，进行我的更改，然后将它们合并回Feature / 1 /？或者我应该根据当前的功能/ 1 /代码创建另一个分支来进行更改吗？
与往常一样，提前感谢答案。
最好的问候。
答案 0 :(得分：1)
问题1：
我会说选项1最符合git flow。此外，如果错误不直接影响 Feature 1 或 Feature 1.1 ，则似乎没有必要将修复程序合并到这些分支。重要的是，修复程序最终会被交付，只要它已经合并到开发人员就可以了。
问题2：
严格的git-flow方式是做一个单独的修复分支。但我个人会对旧的 Feature 1.1 分支进行修复，然后再将其合并到 Feature 1 。无需先将功能1 合并到功能1.1 。
答案 1 :(得分：1)
我认为可以将功能的开发分为三个不同的分支，以便以最佳方式组织工作。
所以我开始研究功能1.1，我已经编写了一些代码，并且在 这样做，我发现了一个错误（与子功能没有直接关系） 1.1或主要特征1），我该怎么办？
我同意第二种解决方案。无论如何，你仍在开发一个未发布的功能。如果此功能已经是master分支的一部分，那么为修复创建单独的分支是有意义的。出于这个原因，我认为使用第一个解决方案没有任何意义。
在我将Feature / 1.1 / branch与Feature / 1 /合并后，我发现了一个 我的Feature / 1.1 /代码中的错误，或者我只想在那里进行一些更改 - 是否可以，切换回Feature / 1.1 /，合并当前功能/ 1 /分支，进行更改，然后将它们合并回Feature / 1 /？要么 我应该根据当前的Feature / 1 / code创建另一个分支 做这些改变吗？
我认为最好和最快的方法是在当前Feature1代码上创建另一个分支，应用修复和合并。
注意：您要求的是关于工作方式的个人意见。无法保证或证明每种创建和合并分支的个人方式是最佳方式。对于我们每个人来说，我们个人的方式是最好的。