使用合并或变基来维护部署分支

Question

使用合并或变基来维护部署分支

gitdeploymentmergebranchrebase

6

我使用AWS进行主机托管，这意味着我无法使用环境变量来控制我的生产和分段部署。因此，我被迫使用单独的分支进行部署，并且想知道是否有最佳实践方法来维护它们？

如果我将更改合并到生产分支中，则包含生产设置的提交将在分支历史记录中丢失，使得调整这些设置更加困难。

然而，我已经阅读过，在这种情况下不应该使用rebase，因为它会使回滚更加困难。

- pingu

1

为什么环境变量和分支是区分不同环境的唯一方法？难道你不能通过传递启动选项来选择使用哪个配置文件，以此实现相同效果吗？ - Magnus Bäck

谢谢你的回复，Magnus。关于AWS Elastic Beanstalk，我不知道有什么方法可以做到这一点。 - pingu

@pingu 从你的问题中并不是完全清楚哪个文件在哪些分支中被覆盖。你能列出某种形式的图表吗（文字足矣）？ - Tim Biegeleisen

4个回答

4

下面有几个链接分享了一些关于方法论的观点，以及为什么应该选择rebase或merge的原因。

合并适用于将代码提交到团队共享分支。由于Rebase重写提交历史，相关提交的上下文（如特征分支）丢失，因为提交以时间戳为基础变得线性。
在提交回共享分支之前，Rebase可以理想地将代码拉入您的工作分支中。线性结果和历史更改可导致更成功的合并提交。

请见：

- Jason W

3

在master上，版本化两个设置文件（settings_master和settings_prod）以及一个符号链接settings -> settings_master。现在，从master分支中分离出prod分支（如果已经存在，则合并master到prod中），并且在prod中，仅修改符号链接settings以指向settings_prod。

将此更改提交到prod中。

现在，在master上进行所有开发工作，并且只要您不修改符号链接本身（更改任何一个设置文件都可以），您就可以随时将master合并到prod中，而不会影响settings的目标。您的应用程序应从settings中检索其配置。

这将导致一个如下所示的提交历史：

... -o---o---o---o  master
      \       \   \
...  --o-------o---o  prod

每次将master合并到prod后，从master到prod的差异总是精确地：

--- a/settings
+++ b/settings
@@ -1 +1 @@
-settings_master
\ No newline at end of file
+settings_prod
\ No newline at end of file

- Thomas Foster

3

您可以版本控制两个设置文件（一个用于开发，一个用于生产）。

然后，您可以留给“elasticbeanstalk/hook”脚本在“git aws.push”之后为您编写实际的设置文件。

您可以在“如何让 Elastic Beanstalk nginx 支持的代理服务器自动从 HTTP 重定向到 HTTPS？”中看到类似问题的示例，该示例是关于一个 Node 应用程序（可能不是您的确切情况），其中 .ebextensions/config 文件将编写 /opt/elasticbeanstalk/hooks/configdeploy/enact/myscript.sh。

最后一个脚本是一个钩子，可以在部署时运行，并且可以更新您的环境的实际配置文件。

- VonC

谢谢您的回复，但我还是有点困惑。当您执行“git aws.push”时，您如何指定环境以便正确的钩子可以运行？ - pingu

使用 eb push 命令，我猜测您是想要实现以下功能：https://forums.aws.amazon.com/ann.jspa?annID=1772 和 http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/command-reference-branch-environment.html - VonC

但这并没有指定您的环境。 - pingu

你可以将你的环境与你的分支关联起来。 - VonC

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Damodaran · Accepted Answer

我最近的项目中也面临了很多实现git的挑战。经过大量搜索，我发现这篇博客是一种维护git分支模型的好方法。 成功的Git分支模型 enter image description here

中央仓库有两个主要分支具有无限生命周期：

- master - develop origin/master 分支对于每个 Git 用户应该都很熟悉。除 master 分支之外，还有另一个称为 develop 的分支。

我们认为 origin/master 是主分支，其中 HEAD 的源代码始终反映出可以投入生产的状态。

我们认为 origin/develop 是主分支，其中 HEAD 的源代码始终反映出最新交付的下一个版本的开发更改的状态。有些人会称其为“集成分支”。这是任何自动夜间构建所构建的地方。 支持分支 我们可能使用的不同类型的分支包括：

- 功能分支 - 发布分支 - 热修复分支

功能分支：功能分支（有时称为主题分支）用于开发即将发布或远期发布的新功能。

可能从以下分支分支出： develop

必须合并回： develop

分支命名约定：除了master、develop、release-或hotfix-之外的任何内容

发布分支：发布分支支持准备新的生产发布。它们允许在最后一刻进行微调。

可能从以下分支分支出： develop

必须合并回： develop和master

分支命名约定： release-*

热修复分支：热修复分支与发布分支非常相似，因为它们也旨在为新的生产发布做准备，尽管是不计划的。它们起源于立即处理现场生产版本的不良状态的必要性。

可能从以下分支分支出： master

必须合并回： develop和master

分支命名约定： hotfix-*

您可以从博客中了解有关此Git分支模型的更多详细信息。用于分支模型的命令也在博客中列出。查看博客以获取更多详细信息。我在我的项目中成功实现了分支模型，并对博客中提到的模型进行了一些更改。Git是一个强大而灵活的工具，这只是使用Git的一种方式。