使用和合并Git分支的正确方法

Question

我阅读了很多文章，但这对我来说仍然不清楚。假设我有一个包含两个分支的项目：master和dev。Dev持有开发分支，master持有稳定分支——准备发布的代码。

问题1：

我想向dev分支添加一些功能，所以我基于dev创建了另一个分支——我们称之为：Feature/1/Some-feature-description，这个功能非常大，所以我将其分成三个不同的分支：Feature/1.1/Some-sub-feature-description，Feature/1.2/Some-sub-feature-description和Feature/1.3/Some-sub-feature-description。

所以我开始处理feature 1.1，我编写了一些代码，在这样做时，我发现了一个错误（与子特性1.1或主要特性1直接相关），我该怎么办？我看到了几种可能的解决方案：

1. 切换回我的dev分支，创建另一个分支（Fix/1/Some-fix-description），修复问题，将Fix分支合并到dev分支中，切换到Feature 1（主要特性分支）从dev合并更改，切换到子特性1.1从dev合并更改。

2. 在Feature 1.1内修复问题（或者根据Feature 1.1创建另一个修复分支，在那里修复问题并将其合并回Feature 1.1分支），当特性完成后，将其与大型Feature 1分支合并，当完成后，将其与dev合并。

在单个和多个开发者项目中，哪种是正确（更好）的方法？也许还有另一种我不知道的方法？

问题2：

在将Feature/1.1/分支与Feature/1/合并后，我发现Feature/1.1/代码中有一个错误，或者我只想在那里进行一些更改——切换回Feature/1.1/，合并当前的Feature/1/分支，进行我的更改，然后将它们合并回Feature/1/，可以吗？还是应该基于当前的Feature/1/代码创建另一个分支来进行更改？

像往常一样，提前感谢您的答案。

最好的问候。

- user2384366

Answer 1

问题1：

我认为选项1最符合git flow。另外，如果错误不直接影响Feature 1或Feature 1.1，似乎没有必要将修复合并到这些分支中。重要的是修复最终会被交付，只要已合并到dev。

问题2：

严格按照git-flow的方式，应该创建一个单独的修复分支。但我个人会在旧的Feature 1.1分支上进行修复，并再次将其合并到Feature 1。无需先将Feature 1合并到Feature 1.1。

- Klas Mellbourn

Answer 2

我认为将功能开发拆分成三个不同的分支以便更好地组织工作是可行的。

所以我开始着手处理功能1.1，我编写了一些代码，在这个过程中，我发现了一个错误（与子特性1.1或主要特性1直接无关），我该怎么办？

我同意第二种解决方案。无论如何，您仍在开发尚未发布的功能。如果此功能已经是您的主分支，则创建单独的分支进行修复是有意义的。因此，我不认为使用第一种解决方案有任何意义。

在Feature/1.1/分支与Feature/1/合并之后，我发现Feature/1.1/代码中有一个错误，或者我只想在那里进行一些更改-切换回Feature/1.1/，合并当前的Feature/1/分支，进行我的更改，然后再将它们合并回Feature/1/，这样做可以吗？还是应该基于当前的Feature/1/代码创建另一个分支来进行更改？

我认为最好和快速的方法是在当前的Feature1代码上创建另一个分支，应用修复并合并。

注意：你所询问的是关于工作方式的个人意见。没有保证或证明每个人创建和合并分支的个人方式都是最好的方式。对于我们每个人来说，我们自己的个人方式才是最好的。

- Alberto Solano

---

感谢您的回答。Q1： 由于我是独自开发我的应用程序，所以这正是我正在做的事情，但是……想象一下：有两个（或更多）开发人员，你发现了一个错误，在你的Feature/1/分支中修复了它，现在你的朋友正在处理不同的功能（让我们称其为Feature/2/），他也发现了相同的错误，并在他的分支中进行了修复，因此我们针对同一问题得到了两个不同的修复方案，在他们尝试将自己的分支合并回dev时出现了冲突——我认为方法1适用于独自工作时，但如果与团队合作，则必须使用方法2。 - user2384366