我正在使用git-svn对我公司的Subversion存储库进行离线开发,Subversion存储库是项目的记录存储库。为了实现管理可见性,我需要在SVN中维护我的功能分支。有时我需要在分支的生命周期内多次将来自主干的更改合并到功能分支。由于我需要在SVN中保持分支最新,我必须合并;一旦他们被推向SVN,我就无法重新提交。此外,git svn dcommit
从合并提交中删除第二个父项。这意味着在第一个git merge
将分支根标识为合并基础而不是最近的合并父级之后的合并。因此,它试图重新合并已经合并的变更,这几乎可以保证令人讨厌的冲突。
当我合并SVN时,我手动指定基本修订版:
svn merge -r 49262:49608 $svn/trunk
git中是否有办法与手动指定的基本修订版合并?
请注意,我需要指定两个修订版本,包括基本版本和父版本。我有像
这样的历史trunk: A -- B -- C -- D -- H -- I
\ \
feature: E -- F -- G -- J -- K
但git svn dcommit
删除了G
和D
之间的父关系。我需要运行I
到K
的合并,其基数为D
。只需运行
$ git checkout feature
$ git merge trunk
将尝试将I
合并到K
,其基数为B
而不是D
,这会重新应用C
和D
导致极端合并冲突。使用SVN,我会运行像
$ svn switch $svn/feature
$ svn merge -r D:I $svn/trunk
但git merge
没有指定基本修订版D
的选项。我正在寻找像
$ git merge --base D trunk
但这样的选项似乎不存在。
答案 0 :(得分:4)
(编辑:对于较低级别的方式,看到以前的版本,这种方式虽然最快)
使用feature
的树在正确的合并基础上进行nonce提交
git checkout `git commit-tree -p $D -m - feature^{tree}`
像往常一样合并主干
git merge trunk --no-commit
git commit # the two-stepper gets the commit message someplace known
将合并树提交为新的feature
提示
git commit-tree -p feature -p trunk -F .git/COMMIT_EDITMSG HEAD^{tree} \
| xargs git checkout -B feature
答案 1 :(得分:0)
您可以尝试git merge <commit hashcode>
使用git log
<强>更新强>
根据您的修订版,我认为您正在寻找的是以下内容。从git branch D
开始。您应该能够通过git status
获取D的提交哈希值。然后,做git checkout feature
。然后做git merge newBranchFromD
。这将使特征状态从主干中的D进入合并状态。
为了保持更清晰的提交历史记录,您还可以在签出功能分支后执行git rebase newBranchFromD
。请注意,这会将H插入到提交历史记录中的正确位置,以便最终得到:
trunkAtD: -- H -- I / trunk: A -- B -- C -- D -- H -- I \ \ feature: E -- F -- G -- H -- I -- J -- K
这与合并提交略有不同,因为rebase会在提交历史记录中按时间顺序放置所有提交。另一个选择是在提交时使用--squash,以便合并不会尝试自动提交。
谨慎使用rebase,因为当你知道它发生了什么事情时它没有被使用会导致意想不到的结果。
答案 2 :(得分:0)
这就是我们所做的。我们首先发现合并提交的哈希失去了它的合并&#39; - MISSING_MERGE,第二个我们发现了提交已合并的提交 - MERGED_POINT。
然后我们去了接收分支并创建了一个假提交
git merge -s ours MERGED_POINT --no-commit
git commit -m "Fake commit because MISSING_MERGE is not marked as a merge commit"
然后我们可以看到
git merge-base OURS THEIRS
我们现在又有了正确的基础。