从分支中提取所有提交,将指定的提交推送到另一个分支

我觉得你要找的词是“樱桃精选”。也就是说,从一个分支的中间获取一个提交并将其添加到另一个分支:

A-----B------C
 \
  \
   D

变成

A-----B------C
 \
  \
   D-----C'

当然,这可以通过git cherry pick命令完成。

这个提交的问题在于,Git认为提交包括它们之前的所有历史记录-因此,如果您有三个这样的提交:

A-----B-----C

为了摆脱B,您必须创建一个全新的提交,如下所示:

A-----------C'

其中c'有一个不同的sha-1 ID。同样,cherry从一个分支到另一个分支选择一个提交,基本上需要生成一个补丁,然后应用它,这样也会丢失历史。

这种提交ID的改变打破了Git的合并功能和其他功能(不过,如果谨慎使用的话,会有一些启发式方法来解决这个问题)。更重要的是,它忽略了函数依赖性——如果C实际使用了在B中定义的函数,您将永远不会知道。

也许处理这种情况的更好方法是拥有更多细粒度的分支。也就是说,不只是拥有一个“master”,而是拥有“featurea”、“bugfixb”等。一次对整个分支执行代码检查-每个分支都非常专注于只做一件事-然后在完成后合并一个分支。这是Git设计的工作流程,它擅长的是:)

如果您坚持在补丁级别处理事情,那么您可能需要查看DARC——它将存储库视为一组补丁,因此挑选樱桃成为基本操作。然而,这也有其自身的一系列问题,例如速度非常慢:)

编辑:另外,我不确定我是否理解你关于这两个脚本的第二个问题。也许你可以更详细地描述它,可能作为一个单独的问题来防止事情变得混乱?

我知道这是一个古老的问题,但这里引用了: How to merge a specific commit in Git

因此,一个更新的答案是:使用特性分支和拉请求。

这看起来是这样的,其中fa是一个带有特性A的commit,fb是一个带有特性B的commit:

            fA   fC (bad commit, don't merge)
           /  \ /
master ----A----B----C
                \  /
                 fB

pull请求与github的功能相关,但实际上我的意思是有人负责将特性分支合并到master中。