Git 将线性历史记录保存在预生产和生产两个分支中

我在github Prepod和production中有两个分支，它们都受到保护并强制执行线性历史记录，这意味着对这些分支的所有更改都需要通过重基/合并或挤压/合并来完成

每一个添加到prepod分支的新特征都由特征分支生成

a          <-- production
 \
  b        <-- preprod
   \
    c -- d <-- featureA

在一些新特性之后，我使用相同的方法挤压/合并将prepod合并到产品中。结果是这样的

a ------------ h     <-- production
 \              ^
  \              \
   b -- e -- f -- g  <-- preprod

a ------------ h ------- k     <-- production
 \              ^         ^
  \              \         \
   b -- e -- f -- g -- i -- j  <-- preprod

更新： 正如@matt正确提到的，这是真实的图形

a ------------ h ------- k     <-- production
 \                       
  \                      
   b -- e -- f -- g -- i -- j  <-- preprod

这解决了冲突，因为我可以只使用prepod上的版本而忽略冲突

我想让这个长寿分支同步并受到保护，因为我有一些github操作运行构建和测试，我认为这两个分支都需要受到保护并具有线性历史记录，因为构建和测试通过后，这两个分支都会自动部署到相应的服务器上。保持线性历史可以让我很容易地看到部署之间的变化，但从预制作到生产的合并正在成为一个瓶颈

---

知道如何解决这个问题吗？

根据我对您流程的理解，我会：

在将prepod合并到prod时不挤压，假设prod分支上没有直接提交，这仍然会给您一个线性历史？ 定期删除prepod分支并从prod重新创建它 或者有选择地定期在prod上重新设置Prepod的基址，但这会稍微复杂一些，不会带来太多好处

---

我强烈倾向于第一种选择，但这是有争议的。

根据我对您流程的理解，我会：

在将prepod合并到prod时不挤压，假设prod分支上没有直接提交，这仍然会给您一个线性历史？ 定期删除prepod分支并从prod重新创建它 或者有选择地定期在prod上重新设置Prepod的基址，但这会稍微复杂一些，不会带来太多好处 强烈倾向于第一种选择，但这是有争议的

这会在每次执行新的拉取请求时产生太多冲突，因为正在尝试合并所有更改

是的，因为这个原因，长寿命的分支和南瓜合并是相反的。你选择了一条不好的路。真正的合并之所以存在，有一个原因：它们为将来的合并移动合并基础。你没有利用这个事实

你的图表是错误的，可能会误导你。例如，您有：

a ------------ h ------- k     <-- production
 \              ^         ^
  \              \         \
   b -- e -- f -- g -- i -- j  <-- preprod

在g和h之间，或者在j和k之间，绝对没有拓扑关系、历史关系或其他关系。相反，h和k是凭空神秘地创造出来的。但它们仍然是使用合并逻辑形成的。用于该合并逻辑的合并基永远不会移动：它将始终是a。因此，随着生活的继续，如果Prepod还活着，你一次又一次地尝试这样做，它将变得越来越难，这反映在越来越多的冲突中

总而言之：您所做的并不是设计重基/挤压合并的目的。这些不是合并。在我看来，你应该放弃你的线性历史的目标——它根本不是历史，这是全部问题。你应该接受真正的合并

这会在每次执行新的拉取请求时产生太多冲突，因为正在尝试合并所有更改

是的，因为这个原因，长寿命的分支和南瓜合并是相反的。你选择了一条不好的路。真正的合并之所以存在，有一个原因：它们为将来的合并移动合并基础。你没有利用这个事实

你的图表是错误的，可能会误导你。例如，您有：

a ------------ h ------- k     <-- production
 \              ^         ^
  \              \         \
   b -- e -- f -- g -- i -- j  <-- preprod

在g和h之间，或者在j和k之间，绝对没有拓扑关系、历史关系或其他关系。相反，h和k是凭空神秘地创造出来的。但它们仍然是使用合并逻辑形成的。用于该合并逻辑的合并基永远不会移动：它将始终是a。因此，随着生活的继续，如果Prepod还活着，你一次又一次地尝试这样做，它将变得越来越难，这反映在越来越多的冲突中

---

总而言之：您所做的并不是设计重基/挤压合并的目的。这些不是合并。在我看来，你应该放弃你的线性历史的目标——它根本不是历史，这是全部问题。你应该接受真正的合并。

你说得对，这是真实的图形，我只是想更明确一点，我会更新这个问题，如果我删除线性历史记录，我还能保持分支的长寿命吗？我设置的CI没有问题吗？你这里的全部问题是假装prod在某种意义上是一个分支。事实并非如此。这只是Prepod的一些行为，与历史无关。a和h之间没有任何联系；h并没有以任何历史方式从a中诞生。随着时间的推移，情况会变得更糟，这正是你现在抱怨的。我认为，大多数人所做的是使用

---

偶尔在一个分支上添加标记，而不是单独的一对分支。换句话说，只要有一个分支prod而不是prepod，当你想把某个东西称为发布时，标记它。听起来不错，谢谢，我会试试看，我只需要知道如何基于标记而不是推送触发部署。或者使用真正的合并。我真的不明白你反对什么。如果你将prod合并到prepod中，可能之前会有一个反向合并，你会得到一个非常好的历史。不反对，我只是想更好地理解它，我刚刚删除了线性历史约束，现在一切都好了，谢谢你，这是真实的图形，我只是想更明确一点，我会更新问题，如果我删除了班轮历史记录，我还能保持分支的长寿命吗？我设置的CI没有问题吗？你这里的全部问题是假装prod在某种意义上是一个分支。事实并非如此。这只是Prepod的一些行为，与历史无关。a和h之间没有任何联系；h并没有以任何历史方式从a中诞生。随着时间的推移，情况会变得更糟，这正是你现在抱怨的。我认为，大多数人所做的是在一个分支上偶尔使用标记，而不是单独的一对分支。换句话说，只要有一个分支prod而不是prepod，当你想把某个东西称为发布时，标记它。听起来不错，谢谢，我会试试看，我只需要知道如何基于标记而不是推送触发部署。或者使用真正的合并。我真的不明白你反对什么。如果你将prod合并到prepod中，之前可能会有一个反向合并，你会得到一个完美的历史记录。不反对，我只是想更好地理解它，我刚刚删除了线性历史约束，现在一切都好了，谢谢

a ------------ h ------- k     <-- production
 \              ^         ^
  \              \         \
   b -- e -- f -- g -- i -- j  <-- preprod

a ------------ h ------- k     <-- production
 \          
  \           
   b -- e -- f -- g -- i -- j  <-- preprod