关于合并分支和良好实践的问题答案

【问题标题】：Question about merge branch and good practices关于合并分支和良好实践的问题
【发布时间】：2020-05-11 05:20:20
【问题描述】：

我的问题可能涉及 git 的基础知识，但我有一些误解，我想从最有经验的 git 开发人员那里获得建议。

我的场景如下：

对于某些项目，我有两个分支preprod 和master

preprod：这个分支用于接收所有开发者的本地开发，一旦客户端验证了这些开发，我将这个preprod分支合并到master

master : 用于生产环境。

场景：

我创建了一个新分支来开发auto-login 功能，

git checkout preprod
git pull
git checkout -b auto_login_v1

我开发了这个功能，我提交（2 个文件），推送然后我将auto_login_v1 分支合并到preprod。 *直到这里一切都很好。

现在我为另一个功能 newsletter 创建一个新分支，

git checkout preprod
git pull
git checkout -b newsletter_v1

和第一步一样，我提交（1 个文件），推送然后我将 newsletter_v1 分支合并到 preprod。

现在我的客户告诉我在生产环境中部署时事通讯功能，所以我将newsletter_v1 分支合并到master。

问题是通过合并第二个分支newsletter_v1，其中包含（基本上是1个文件），无意中，我还合并了第一个分支auto_login_v1的（2个文件），而我只想要第二个分支newsletter_v1 和（1 个文件）。

为什么我得到了这个（部署了 3 个文件而不是 1 个）？因为我在preprod 中合并了第一个分支然后我拉了它？

2) 在我们只想合并一个特性（分支）而不合并另一个特性（分支）的情况下，推荐的良好做法是什么？

【问题讨论】：

回答问题 2：如果您想推迟发布所有正在运行的功能，请不要将它们合并到将进入 prod 的分支中。你应该阅读git flow。
好的@Lasse V. Karlsen，谢谢
@Lasse V. Karlsen 因此，如果我理解正确，我们必须只将功能分支合并到 develop 中？所以在我的场景中，我创建了一个新分支release（develop 和 master 之间的中介），我将 develop 合并到 release，然后在这个release 中，我恢复了我不想要的合并分支 master @ 987654350@ 最后，我将 release 合并到 master 并合并到 'develop' 中？之后如果我想重新申请auto_login_v1，因为客户端刚刚验证了它，我创建一个新分支auto_login_v2，其工作与auto_login_v1 相同，并将其合并到开发中？

标签： git github merge branch

【解决方案1】：

I developped this feature, I commited (2 files), pushed then I merged auto_login_v1 branch into preprod. *Until here everything is good.

嗯...我想这一切都取决于你所说的好。您正在将代码推送到开发中，可能没有完成，然后当您从它开始分支时，您可能有来自其他功能的代码......然后如果您合并这个其他功能（当您在第二个分支上做了）进入master，你肯定携带未完成的代码......实际上不需要代码，因为客户端只请求了一个功能，而你携带的不仅仅是通过合并开发。

所以....即使您将功能分支直接推送到开发中（我不同意该工作流程，但是，嘿！如果您喜欢这样，我该判断谁？），如果您被要求将单个功能合并到 master 中，您将不将 develop 合并到 master 中......您不要将功能分支合并到 master 中...您带来修订仅与 master 之上的功能相关。

所以...好习惯：

你可以尝试无数的工作流程，但可能 gitflow 是最受欢迎的......你可以在上面添加你喜欢的东西，但这绝对是一个很好的起点。

https://datasift.github.io/gitflow/IntroducingGitFlow.html

祝你好运

【讨论】：

【解决方案2】：

我遵循了你描述的提交，并从一个名为 SourceTree 的程序中截取了屏幕截图，以帮助可视化分支。

希望您可以看到，一旦将分支合并到 preprod，任何从 preprod 签出的分支都必然会继承合并后的更改。

就最佳实践而言，一种流行的分支策略称为 GitFlow，它与您已经在做的类似。 GitFlow 为特定目的指定特定分支：

master：保留版本发布
develop：保留用于合并功能分支（相当于你的preprod 分支）
发布分支：在将develop 合并到master 之前，您应该检查一个中间“发布”分支。您从develop 分支的提交不必是develop 的负责人。

这里有一篇关于 GitFlow 的深入文章，因为它还有更多内容：https://docs.microsoft.com/en-us/azure/architecture/framework/devops/gitflow-branch-workflow

在您确定要将其包含在下一个版本中之前，您不应将功能分支合并到 develop。

从auto_login_v1 中“删除”preprod 中的合并更改的一种方法是git revert。

看看How to revert a merge commit that's already pushed to remote branch?或看看git revert documentation

【讨论】：

感谢您的宝贵时间 +1，我不明白仅合并 newsletter_v1 而没有其他分支的解决方案？
In the future you should not merge... 但是develop是链接到客户端测试特性的测试环境，是不是这种情况，如果我理解正确的话，我们必须只将特性分支合并到develop中？所以在我的场景中，我创建了一个新分支 release（develop 和 master 之间的中介），我将 develop 合并到 release，然后在这个 release 中，我恢复了我不想要的合并功能 auto_login_v1最后，我将 release 合并到 master 并合并到 'develop' 中？