【问题标题】:Pushing selected changes to production将选定的更改推送到生产中
【发布时间】:2015-04-03 02:10:22
【问题描述】:

我正在将 Git/Heroku 用于工作应用程序。通常,更改将被合并到 master 然后推送到 staging 然后生产。但现在我只需要将选定的更改(补丁)推送到生产环境。我该怎么做?

  1. master 中的一些初始状态
  2. 补丁 1
  3. 补丁 2
  4. 补丁 3
  5. 补丁 4
  6. 补丁 5

我的第一个想法是退出 heroku/production。在此处复制更改(例如,可能来自补丁 2 和 4 的子集),然后仅推送到 heroku 生产。我认为这将在短期内奏效。但是将来我如何管理这种“发散”的变化?由于现在掌握和生产是不同的。当我从 master 推送到生产中时,我想我会遇到冲突?要么这样,要么我最终会覆盖对生产所做的更改?如何管理这些变化?

【问题讨论】:

    标签: git deployment version-control


    【解决方案1】:

    但是将来我如何管理这种“发散”的变化?

    通过创建一个专用分支“prod”,您可以从中 cherry-pick 正确提交您想要从 master(而不是全局合并)

    由于现在master和production是不同的。当我从 master 推送到生产时,我想我会遇到冲突?

    是的:一旦你开始挑选提交,你就不应该再合并了。
    (因为duplicate commitsfunctional dependencies

    这两个分支之间的最佳协调是使master 足够稳定以替换 prod 分支(意味着您将prod 重置为master

    我在compileEverything project 中正是采用这种“双分支”方法。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2011-11-24
      • 2011-11-16
      • 2011-09-21
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2020-06-15
      相关资源
      最近更新 更多