git提交给所有分支机构 [英] git commit to all branches

问题描述

如果我在分支 branch_a 中的文件中修正了一个应该应用于所有分支的bug。有没有一种方法可以将更改应用到所有分支，而无需单独检出分支。

  git commit -m'commit msg '＃分支a 
 
 git结帐branch_b 
 git樱桃挑选branch_a 
 
 git结帐branch_c 
 git樱桃挑选branch_a 
  

我想要的是 git commit --to-all-branches 它会尽可能将更改传播到所有分支。

编辑

为了澄清一下我的情况，我编写代码来解决计算问题。通常我最终会遇到哪种方法最能解决给定问题的情况。所以我创建了一个分支。这些分支往往分歧，更像叉子。但是为了保持所有的文件，我只是使用一个Git仓库与多个分支。在与所有分支/分支相关的错误情况下，我一直在寻找自动更新所有分支。

或者严格来说，是的，但其他任何方式都是一样的。新的提交总是添加到当前分支，即使这是分离的HEAD 。 （下面，我将展示一种使用分离HEAD状态的方法，尽管如果您将现有分支提示的提交添加到工作区，那么只需检查它们即可）。

假设您有这样的事情：

  ABC < -  br1 
 \ 
 DF < -  br2 
 \ / 
 E 
 \ 
 G < -  br3 
  

，并且您有一些必须应用于顶部的修正 X > C ， F 和 G 给出：

  ABC-X1 < -  br1 
 \ 
 D F-X2 < -  br2 
 \ / 
 E 
 \ 
 G-X3 < -  br3 
  

（请注意，所有3 Xn 提交都是不同的提交，因为它们具有不同的父级），那么您必须添加patch X code> C ，然后添加patch X来提交 F ，然后添加patch X来提交 G 。

请注意， ，例如，从 C 到 X1 的变化与 F 到 X2 。你可以用通常的方式首先构造三个 Xn 提交中的任何一个。然后（如你的问题），你只需移动到其他分支， git cherry-pick 创建（并可能解决冲突）其他 X -es。但是你需要在这些分支上添加提交，所以：

  $ git checkout br1 
 ... make fix，git add，git commit创建X1 
 
 $ git checkout br2 
转换到分支'br2'。 
 $ git cherry-pick br1＃获得`C` -`-X1`的差异，应用于`F`以使`X2` 
 ...等
  

对所有必须复制修补程序的分支重复（并在必要时修改以适应该分支）。

---

还有其他方法可以做到这一点。例如，假设分支 br1 确实可以，您发现的是 E 被破坏并且需要被修复，影响提交 F 和 G 。进一步假设没有其他人拥有提交 F 和 G - 或者，我们愿意强迫那些做这两件事的人去做一些工作，以便从你将要做的事情中恢复过来。在这种情况下，你可以签出commit D ，并创建一个新的提交， E' code> d 。让我们从出发点出发，通过 C 来省略 A 。我们将使用 git checkout D （通过它的SHA-1，或者等价地使用这个图表 - 通过使用 br2〜2 命名它）在那里得到一个分离的HEAD：

  D < -  HEAD 
 | 
 | F < -  br2 
 \ / 
 E 
 \ 
 G < -  br3 
  

现在：

  $ git cherry-pick -n br2 ^＃make E的一个副本，但不要提交
＃编辑来修复它
 $ git commit＃make new commit E'是固定的
  

一旦提交完成，我们有了这个（仍然用detached HEAD ）：

  E'<  -  HEAD 
 / 
 | 
 | 
 D 
 | 
 | F < -  br2 
 \ / 
 E 
 \ 
 G < -  br3 
  

现在我们可以复制commit F 到 F'：

  $ git cherry-pick br2 
  

给出：

  F'< -  HEAD 
 / 
 E'
 / 
 | 
 | 
 D 
 | 
 | F < -  br2 
 \ / 
 E 
 \ 
 G < -  br3 
  

现在我们准备让 br2 引用commit F'：

  $ git branch -f br2 HEAD 
  

给出：

  F'< -  HEAD，br2 
 / 
 E'
 / 
 | 
 | 
 D 
 | 
 | F [弃用] 
 \ / 
 E 
 \ 
 G < -  br3 
  

（这是我上面写的严格说来部分：您可以将提交添加到存储库，然后移动分支标签，以便标记新的提交链，而不是它们的标签所有添加的提交都会移动 HEAD ：只要 HEAD 是对分支的引用，它们 在工作时向前迈进一步。 HEAD 引用分支是正常的工作方式，但你可以在事实上，在detached HEAD模式下使用 git branch -f 。在这种情况下，我正在做这个来创建新的 br2 而不使用分支名称​​ ，然后在分支名称准备就绪时将分支名称移至新的提交链。）

现在我们需要将 G 复制到 G'，附加 G'到 E'。以下是步骤：

$ $ $ $ g $ check $ br $ ^＃返回E'作为分离的HEAD
[git在这里说移动分离的HEAD的东西]
$ git cherry-pick br3＃复制提交G
$ git分支-f br3 HEAD＃并在此移动br3标签

（这是我们将 F 复制到 F' ，或多或少）给出：



  F'< -  br2 
 / 
 E'
 / \ 
 | G'<  -  HEAD，br3 
 | 
 D 
 | 
 | F [弃用] 
 \ / 
 E 
 \ 
 G [弃用] 
  

完成所有工作后，您应该 git checkout somebranch 来取回在分支上，并且远离分离HEAD状态。



正如评论中指出的那样，需要广泛应用补丁（这是一个词？），因为这表明可能有错误整个过程。 （但是，这是固定日零错误的样子，当你有一堆不同的产品与日零错误共享代码库时）。

If I fixed a bug in a file in branch branch_a, which should be applied to all branches. Is there a way to apply the change to all branches without having to checkout the branches individually.

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

What i would like to have is a git commit --to-all-branches which tries to propagate the changes to all branches if possible.

Edit

To clarify a bit my situation, I write code to for computational problems. Often I end up in the situation where it is unclear which approach is the best solve a given problem. So i create a branch. These branches tend to diverge and are more like forks. However to keep all the files in place I just use one git repository with multiple branches. In the situation of a bug relevant for all branches/forks I was looking for away to update all branches automatically.

解决方案

No—or strictly speaking, "yes, but it's just as much work any other way". New commits are always added to "the current branch", even if that's a "detached HEAD". (Below, I'll show a way of doing this with the "detached HEAD" state, although if you're adding commits to existing branch-tips, that's more work than just checking them out.)

Assuming you have something like this:

A-B-C          <-- br1
   \
    D   F      <-- br2
     \ /
      E
       \
        G      <-- br3

and you have some fix X that must be applied on top of C, F, and G to give:

A-B-C-X1       <-- br1
   \
    D   F-X2   <-- br2
     \ /
      E
       \
        G-X3   <-- br3

(note that all 3 Xn commits are different commits as they have different parents), then you must add "patch X" to commit C, and then add "patch X" to commit F, and then add "patch X" to commit G.

Note that there is no guarantee that, e.g., the change from C to X1 exactly matches the change from F to X2 here, either. You may construct any of the three Xn commits first, in the usual way. Then (as in your question) you just move to the other branches and git cherry-pick to create (and possibly resolve conflicts in) the other X-es. But you need to be "on" those branches to add commits to them, so:

$ 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

Repeat for all branches to which the patch must be copied (and, if necessary, modified to fit that branch).

---

There are alternatives to doing this. For instance, suppose branch br1 is actually OK, and what you've discovered is that commit E is broken and needs to be fixed, affecting commits F and G. Suppose further that either no one else has commits F and G—or, you're willing to force those who do have those two commits, to do a bunch of work to recover from what you are about to do. In that case, you can check out commit D and make a new commit, E', that comes off of D. Let's draw the starting point, leaving out A through C. We'll git checkout D (by its SHA-1, or—equivalently with this graph—by using br2~2 to name it) to get a "detached HEAD" there:

D       <-- HEAD
|
|   F   <-- br2
 \ /
  E
   \
    G   <-- br3

Now:

$ 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

Once the commit finishes, we have this (still with the "detached HEAD):

  E'    <-- HEAD
 /
|
|
D
|
|   F   <-- br2
 \ /
  E
   \
    G   <-- br3

Now we can copy commit F to F':

$ git cherry-pick br2

giving:

    F'  <-- HEAD
   /
  E'
 /
|
|
D
|
|   F   <-- br2
 \ /
  E
   \
    G   <-- br3

We're now ready to make br2 refer to commit F':

$ git branch -f br2 HEAD

giving:

    F'  <-- HEAD, br2
   /
  E'
 /
|
|
D
|
|   F   [abandoned]
 \ /
  E
   \
    G   <-- br3

(This is the "or strictly speaking" part I wrote above: you can add commits to a repository, then move branch labels around so that they label the new commit chains, rather than their old ones. All added commits move HEAD: it's just that if HEAD is a reference to a branch, they also move the branch one step forward as you work. Having HEAD refer to a branch is the "normal" way of working, but you can fake it after-the-fact in "detached HEAD" mode with git branch -f. In this case, I'm doing that to build the new br2 without using a branch name, then moving the branch name to the new chain of commits once it's ready.)

Now we need to copy G to G', attaching G' to E'. Here are the steps:

$ 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

(this is what we did for copying F to F', more or less) giving:

    F'  <-- br2
   /
  E'
 / \
|   G'  <-- HEAD, br3
|
D
|
|   F   [abandoned]
 \ /
  E
   \
    G   [abandoned]

Once you're all done, you should probably git checkout somebranch to get back "on a branch", and away from this "detached HEAD" state.

As noted in comments, needing to apply a patch as wide-spread-ly (is that a word?) as this suggests that maybe there's something wrong with the whole process. (But this is what fixing a "day zero bug" looks like when you have a bunch of different products that all share the code-base with the day-zero bug.)

这篇关于git提交给所有分支机构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！