git提交所有分支

gre*_*ole 13 git commit

如果我修复了分支中的文件中的错误,该错误branch_a应该应用于所有分支.有没有办法将更改应用于所有分支,而无需单独检出分支.

git commit -m 'commit msg' # on branch a 

git checkout branch_b
git cherry-pick branch_a

git checkout branch_c
git cherry-pick branch_a
Run Code Online (Sandbox Code Playgroud)

我希望有一个 git commit --to-all-branches尝试将更改传播到所有分支的可能性.

编辑

为了澄清我的情况,我编写代码来解决计算问题.通常情况下,我不知道哪种方法最能解决特定问题.所以我创建了一个分支.这些分支往往发散,更像是叉子.但是为了保留所有文件,我只使用一个带有多个分支的git存储库.在与所有分支/分支相关的错误的情况下,我正在寻找自动更新所有分支.

tor*_*rek 12

不 - 或严格来说,"是的,但它的工作方式与其他方式一样多".新提交总是添加到"当前分支",即使这是"分离的HEAD".(下面,我将展示一种使用"分离的HEAD"状态执行此操作的方法,但是如果您要向现有的分支提示添加提交,那么除了检查它们之外,还有更多的工作.)

假设你有这样的东西:

A-B-C          <-- br1
   \
    D   F      <-- br2
     \ /
      E
       \
        G      <-- br3
Run Code Online (Sandbox Code Playgroud)

和你有一些修正X,但必须在上方应用C,F以及G给:

A-B-C-X1       <-- br1
   \
    D   F-X2   <-- br2
     \ /
      E
       \
        G-X3   <-- br3
Run Code Online (Sandbox Code Playgroud)

(请注意,所有3个Xn提交都是不同的提交,因为它们具有不同的父级),然后必须添加"patch X"进行提交C,然后添加"patch X"进行提交F,然后添加"patch X"进行提交G.

需要注意的是有没有保证,例如,从变化CX1正好从变化匹配FX2这里,无论是.您可以Xn以通常的方式首先构造三个提交中的任何一个.然后(如你的问题)你只需要移动到其他分支并git cherry-pick创建(并可能解决冲突)其他X-es.但是你需要"在"那些分支上添加提交给它们,所以:

$ git checkout br1
... make fix, "git add", "git commit" to create X1

$ git checkout br2
Switched to branch 'br2'.
$ git cherry-pick br1    # take diff of `C`-vs-`X1`, apply to `F` to make `X2`
... etc
Run Code Online (Sandbox Code Playgroud)

对必须复制补丁的所有分支重复(如有必要,修改为适合该分支).


这样做还有其他选择.例如,假设分支br1实际上是正常的,您发现的是提交E被破坏并需要修复,从而影响提交FG.进一步假设,要么没有人拥有的提交FG-or,你愿意迫使那些谁你即将做什么有那些两次提交,做一堆的工作,从恢复的.在这种情况下,你可以检查出承诺D,并作出新的承诺,E'即脱落的D.让我们画一个起点,而忽略了A通过C.我们git checkout D(通过它的SHA-1,或等效地用这个图表 - 通过使用br2~2命名它)来获得一个"分离的HEAD":

D       <-- HEAD
|
|   F   <-- br2
 \ /
  E
   \
    G   <-- br3
Run Code Online (Sandbox Code Playgroud)

现在:

$ git cherry-pick -n br2^  # make a copy of E but don't commit yet
# edit to fix it
$ git commit               # make new commit E' that's fixed
Run Code Online (Sandbox Code Playgroud)

一旦提交完成,我们就有了这个(仍然使用"分离" HEAD):

  E'    <-- HEAD
 /
|
|
D
|
|   F   <-- br2
 \ /
  E
   \
    G   <-- br3
Run Code Online (Sandbox Code Playgroud)

现在我们可以将提交复制FF':

$ git cherry-pick br2
Run Code Online (Sandbox Code Playgroud)

赠送:

    F'  <-- HEAD
   /
  E'
 /
|
|
D
|
|   F   <-- br2
 \ /
  E
   \
    G   <-- br3
Run Code Online (Sandbox Code Playgroud)

我们现在准备br2参考提交F':

$ git branch -f br2 HEAD
Run Code Online (Sandbox Code Playgroud)

赠送:

    F'  <-- HEAD, br2
   /
  E'
 /
|
|
D
|
|   F   [abandoned]
 \ /
  E
   \
    G   <-- br3
Run Code Online (Sandbox Code Playgroud)

(这是我上面写的"严格来说"部分:你可以将提交添加到存储库,然后移动分支标签,以便它们标记新的提交链,而不是旧的提交链.所有添加的提交都会移动HEAD:它只是那个如果HEAD是对分支的引用,它们也会在您工作时将分支向前移动一步.HEAD引用分支是"正常"工作方式,但您可以在"分离HEAD"模式下伪造它用git branch -f.在这种情况下,我这样做,要建立新的br2不使用分支的名称,然后移动分公司名义提交的处理完成后,新的链条.)

现在我们需要复制GG',附加G'E'.以下是步骤:

$ git checkout br2^      # get back on E' as a detached HEAD
[git says stuff here about moving the detached HEAD]
$ git cherry-pick br3    # copy commit G
$ git branch -f br3 HEAD # and move br3 label here
Run Code Online (Sandbox Code Playgroud)

(这是我们为复制F而做的F',或多或少)给予:

    F'  <-- br2
   /
  E'
 / \
|   G'  <-- HEAD, br3
|
D
|
|   F   [abandoned]
 \ /
  E
   \
    G   [abandoned]
Run Code Online (Sandbox Code Playgroud)

一旦你完成了所有,你应该git checkout somebranch回到"在一个分支上",并远离这个"独立的HEAD"状态.

正如评论中所指出的那样,需要广泛应用补丁(这是一个单词?),因为这表明整个过程可能存在问题.(但是当你有一堆不同的产品都与零日bug一起共享代码库时,这就是修复"白天零错误"的原因.)


Pet*_*ton 5

这并不存在,因为每次合并都可能导致需要用户干预的单独冲突。您将需要编写脚本来执行所需的操作。