我正在使用git-svn;我通常创建一个主题分支,提交它,然后checkout master,git svn rebase,git merge --squash topic_branch,git commit -m“summary comment”,然后是git svn dcommit。
这很好,但是git似乎并不知道我将分支更改合并到master中。我在没有涉及svn的情况下尝试了这个:
# Make a repository, add a couple files
$ mkdir gittest
$ cd gittest
$ git init
$ touch foo bar
$ git add .
$ git commit -m "initial version"
# Make a branch, change a file, commit.
$ git checkout -b a_branch
$ vi foo # make a change
$ git commit -am "a change"
# Merge changes into master
$ git checkout master
$ git merge --squash a_branch
$ git commit -m "merged a_branch"
和gitk --all显示了这一点,这表明它不是git-svn问题:
在我的主要(git-svn)项目中,我看到早期的一些变化看起来似乎已合并,但我不知道我现在做的不同,因为我当时没有做。 (如果重要的话,这是关于Ubuntu Jaunty的git 1.6.0.4。)
答案 0 :(得分:8)
我认为这是因为您使用了--squash
。我不确定你为什么这样做,但你不应该这样做。来自git merge的--squash
文档:
生成工作树和索引 状态好像发生了真正的合并,但是 实际上不做提交或移动 HEAD,也没有记录 $ GIT_DIR / MERGE_HEAD导致下一个 git commit命令用于创建合并 承诺。这允许您创建一个 在当前的单一提交 分支的效果与 合并另一个分支(或更多) 章鱼的情况。)
基本上,您需要进行“正确”合并。压扁似乎有一个相当具体的使用情况(我从来没有过,所以我不能真正评论为什么它有用)。我猜如果你不希望分支树看起来很乱,如果你在一个分支中做了一些工作但是后来又决定将它合并到一个不同的分支中,你正在做更多的总体工作
答案 1 :(得分:3)
请勿使用git merge --squash
:)
答案 2 :(得分:1)
加上Peter Cooper的回答(评论不够长):
git rebase --interactive
(虽然电锯危险:请参阅http://tomayko.com/writings/the-thing-about-git了解更多信息和一些背景,了解您为什么要使用它)将让您在将它们提交给svn之前压缩并重新排序各个提交。我用了很多东西来帮助将10-12个中间提交合并到3-4个补丁集中,然后再回到repo。
尝试git rebase --interactive HEAD~10
以交互方式重新定义当前分支上的最后10个提交。一旦你学会它,它就会非常好,我每天都会在我的git svn repo上使用它。
答案 3 :(得分:1)
在你进行壁球合并后,你需要手动告诉git你的合并,因为在你提交git忘记之后。手动告诉git关于你的合并的方法是使用git grafts。 link text