如果我修复了分支中的文件中的错误,该错误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.
需要注意的是有没有保证,例如,从变化C到X1正好从变化匹配F到X2这里,无论是.您可以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被破坏并需要修复,从而影响提交F和G.进一步假设,要么没有人拥有的提交F和G-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)
现在我们可以将提交复制F到F':
$ 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不使用分支的名称,然后移动分公司名义提交的处理完成后,新的链条.)
现在我们需要复制G到G',附加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一起共享代码库时,这就是修复"白天零错误"的原因.)
| 归档时间: |
|
| 查看次数: |
7545 次 |
| 最近记录: |