管理相关的进行中git功能分支/分支集

管理相关的进行中git功能分支/分支集,git,workflow,feature-branch,Git,Workflow,Feature Branch,最近,我似乎有这样一个重复的场景:正在开发多个功能分支,一个功能分支(下图中的feature-b)取决于对另一个未完成功能的支持(在feature-a中开发): 每当我修改feature-a(包括交互式重定基址以修复功能中的错误)时,我需要将feature-b重定基址到feature-a。这些是本地分支,所以我可以随时修改它们 我经常遇到以下情况: master testing ---o--

最近,我似乎有这样一个重复的场景:正在开发多个功能分支,一个功能分支(下图中的
feature-b
)取决于对另一个未完成功能的支持(在
feature-a
中开发):

每当我修改
feature-a
(包括交互式重定基址以修复功能中的错误)时,我需要将
feature-b
重定基址到
feature-a
。这些是本地分支,所以我可以随时修改它们

我经常遇到以下情况:

             master                                         testing
---o---o--o-------------------------------------------o---o
       |              feature-a                      .   .
       +---o---o---o                                .   .
                   |           feature-b           .   .
                   +----o---o .....................   .
                   |           feature-c             .
                   +----o---o .......................
其中,测试分支是正在开发的所有(相关)特征的组合,通过合并其上的所有相关特征分支(在图片
master
feature-b
feature-c
——以及暗示
feature-a
)生成

目前,特别是如果具有更复杂的功能分支关系,我会不断打开
gitk
以可视化分支关系,并维护shell脚本以自动执行此重定基调,但这种方法似乎很脆弱,而且是一种常见的麻烦。我想知道的是:

  • 是否有一种方法可以描述甚至自动检测分支关系,然后使用一个命令尝试重新执行所描述的关系(在上面的简单示例中,通过重定基址或向标头添加新提交来更改
    feature-a
    后,在
    feature-a
    的新标头上自动重定基址
    feature-b
  • 用于将一组分支重新定位到其他提交的GUI工具(如果冲突会阻止操作,只需给出错误就可以了)
  • 管理这个分支机构混乱局面的其他想法?涉及的意外复杂性成本太高 时间和消耗太多的脑力
  • 我不喜欢把不好的东西推给别人看,我喜欢保留最后的结果 历史看起来一清二楚

    这是一个坏习惯。你应该保留一个
    master
    和一个
    pu
    “建议的更新”。将你的承诺推到
    pu
    ,然后根据需要将
    pu
    重设为
    master
    。时机成熟时,你可以从
    pu
    中挑选,甚至将
    pu
    合并到
    master

    这就是它自己的做法。避免掉进无休止的分支的“兔子洞”


    在我看来,这更像是你需要考虑你的功能和分支,而不是用脚本来修复。依赖的功能已经是一种气味。首先完成分支,将其集成,然后开始新的工作。我知道这听起来比它简单,但是最好的解决方案。我可以看出你可以找到一些气味在依赖特性的概念中,我想这是因为我太喜欢git提供编辑我的[尚未发布]提交的可能性的方式;我不喜欢把不好的东西推给别人看,我喜欢保持最后的历史记录干净(例如为了代码审查).另一方面,我认为拥有更灵活的工具可以让工作流程更灵活;对独立的私有分支机构的自然支持将使我在当前的开发环境中的工作更轻松。我不认为重新设置分支机构基础的能力对“完成一件事,然后再做下一件事”有什么影响。最近的一个例子是“相关功能”:自动生成的代码(来自数据描述语言);为了满足功能需求,我需要扩展设施。为了表达清晰,我正在开发通用支持和单独分支中的一个功能需求。后者用作通用支持的测试用例(一旦通用支持证明有效,其他类似要求将在其分支机构中实施)。然后,我可能会在私人分支中维护各种个人调试注释或实验。
    git
    是一个功能强大的工具,支持不同的工作流组织方式。这只是我个人缺少的一个,可能最终实现了它来治好我的痒,但我想首先知道是否已经存在某些东西。我不能仅仅改变我的组织的工作流程。我同意完美主义/拖延是值得质疑的——特别是如果被检测为一种习惯的话。但这只是拥有如此挥之不去的私有分支机构的一个(次要)原因。从概念上讲,我在公共代码中缺少了一些类似私有层的东西(从技术上讲,它们只是补丁,可以作为本地分支实现)。
                 master                                         testing
    ---o---o--o-------------------------------------------o---o
           |              feature-a                      .   .
           +---o---o---o                                .   .
                       |           feature-b           .   .
                       +----o---o .....................   .
                       |           feature-c             .
                       +----o---o .......................