我的工作流程如下:
但是我的历史看起来像这样:
commit c37c0b495e6cede93dd359201e14af46f7d4bbaf
Merge: 93f526c e72b831
Author: ...
Date: Mon Dec 2 10:29:13 2013 +0200
Merge branch 'X'
commit e72b831f8b2d78ac6650190f062dfd1065551f64
Author: ...
Date: Mon Dec 2 10:28:45 2013 +0200
The new features that X introduced.
我的问题是如何在历史记录中删除Merge分支“X”消息,以便将提交从分支X推送到上游存储库而不是弄乱那里的历史记录?
由于
答案 0 :(得分:1)
在合并之前尝试重新绑定。
我的工作流程:
答案 1 :(得分:0)
合并提交不会“弄乱分支”,但如果您想避免合并提交,请尝试rebasing。
即。不是将您的提交从X
合并到master
,而是在X
之上重新master
,这有效地“重播”您的提交,从而集成更改而无需合并提交
答案 2 :(得分:0)
如果你不想拥有这个" Merge Branch" (这称为合并提交)您需要 rebase 您的提交到master
。
您可以分两步完成此操作:
1。)如果master
不与origin/master
保持同步,则在进入第2步之前必须执行以下操作
git fetch
git checkout master
git merge origin/master
2。)如果您的master
与origin/master
保持同步,请执行以下操作:
git rebase master X
git checkout master
git merge X
git push
这样你就不会得到你正在谈论的合并提交。
有人添加评论后更新:
git rebase --onto
已记录在案Git - Rebasing。
它基本上做了以下。鉴于以下git历史:
hash1 (master origin/master)
|
hash2 (X origin/X)
hash3 commit3
hash4 commit4
hash5 commit5
| /
hash6 commit6
如果你执行
git rebase --onto master commit5 X
然后Git将commit5
(不包括)和X
(包括)之间的所有内容都移到master
的op上,所以它看起来像这样:
hash2 X
hash3 commit3
hash4 commit4
hash1 (master origin/master)
|
hash2 (origin/X)
hash3 commit3
hash4 commit4
hash5 commit5
| /
hash6 commit6
正如您所看到的,X
不是master
之前的3次提交,而origin/X
仍然在其上#34;旧的"的地方。
如果你没有origin/X
,分支就会消失(因为它已移动)。但是,如果您希望origin/X
移动"移动"到X
,你必须推动这个特定的分支
git push --force origin X
答案 3 :(得分:0)
首先,我将使用reference link
当git有2个分支并希望合并它们时,它会创建一个名为merge commit
的新提交,这个提交引入了两个树的差异,因为它们是共同的父
@ {3}}
中的图3-17合并未创建合并提交的唯一时间是合并是快进合并
@figure 3-12 reference link
因此,避免合并提交的唯一选择是reference link
答案 4 :(得分:0)
是的,因为每个人都说你可以使用rebase,但我不建议这样做。如果您遵循工作流程,其中每个分支代表新功能,并且您希望能够读取历史记录并了解这些更改来自哪个分支,则应保留这些合并消息。我唯一建议的是:在git pull期间使用rebase策略。