Git重复合并压扁 [英] Git merge squash repeatedly

查看:96
本文介绍了Git重复合并压扁的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我试图在git中使用二进制文件的两个分支 - 一个开发和一个稳定。在我想将它们释放到稳定分支之前,开发分支可以对这些文件进行一些更改(并且在相关情况下,稳定分支将这些文件重命名)。



我可以做一个正常的合并,这工作正常,但保留了太多的历史 - 当拉动稳定分支时,所有来自开发分支的中间提交也被拉下(因为它们是父提交)。但是我们讨论的是没有任何明智的合并策略的二进制文件(除了他们的/我们的),所以开发分支上文件的实际历史记录是无用的。当我拉稳定分支,我得到这个:

 
X -------------- ----- G稳定
/ /
a --- b --- c --- d --- e --- f --- g开发

因为G在开发分支中有父项,所以我在我的开发分支(c,d,e,f和g的数据对象)版本库,我不感兴趣(X与b一样,应用了一些文件重命名)。



所以我试着 git合并--squash 从开发分支到稳定分支的变化。第一次这样的合并和提交是OK的,结果如预期的那样(提交消息中的更改日志,与开发分支没有关系):

 X ------------------- G stable 
/
a --- b --- c --- d --- e --- f --- g development

在我将这个压扁的稳定分支拉出后,我在我的存储库中得到了这个,这正是我想要的:

 
a --- b --- X --- G



<但是第二次合并失败了(因为git无法知道我已经合并了多少,并且感到困惑)。


  • 是否有可能以某种方式记录合并,而不会与两位父母产生合并提交?或者,是否可以告诉git合并修订的某个范围,比如在SVN中?

  • 或者,是否有可能进行正常合并,而无需在下拉时从另一个分支下载所有ref?

  • 或者我应该提供f的自定义合并驱动程序iles,只是简单地将他们的版本改名为我们,从而解决冲突?我仍然担心 - squash 会一直尝试合并整个历史记录,直至共同的父项,只解决我的一半问题。








  • $ p $如果我能正确理解rebasing,最后会有这样的结果:

     
    X stable
    /
    a --- b --- c-- -d --- e --- f --- g开发

    从哪得到我所不感兴趣的所有数据c,d,e,f),作为奖励,我将放弃b在分支中是稳定版本的信息。

    每个开发版本增加了大约5MB到仓库大小(并重新包装整个仓库只收缩约10%),稳定分支几乎是免费的(数据已经存在)。我想从稳定的分支中提取一个新的修订版以仅提取新的5MB,但是从X更新到G下载25MB,因为我无法说我不关心c的内容,d ,e和f。

    解决方案

    开始

      X stable 
    /
    a --- b --- c --- d --- e --- f --- g开发

    您可以使用以下步骤将开发分支中的最后一个提交复制到稳定分支:

      git checkout development @ {0}#从开发中获取工作树,分离HEAD 
    git reset --soft stable#重新定位detached HEAD on稳定的
    git commit#输入适当的提交信息
    git branch temp#在HEAD
    创建临时分支tempgit checkout temp#获取新的临时分支
    git分支-M stable#将temp重命名为stable

    s你最终得到:

      X ------------------- G稳定
    /
    a --- b --- c --- d --- e --- f --- g开发

    如果您继续进行开发工作,例如

      X ------------------- G stable 
    /
    a --- b --- c --- d --- e- --f --- g --- h --- i --- j开发

    你可以重复使用与上面相同的git命令,并且最终会得到:

      X ---------- --------- G ----------- J stable 
    /
    a --- b --- c --- d --- e- --f --- g --- h --- i --- j开发


    I'm trying to have two branches with binary files in git - one "development" and one "stable". The development branch can have several changes of these files before I want to "release" them to the stable branch (and the stable branch has those files renamed, in case that's relevant).

    I could do a normal merge, this works fine, but preserves too much history - when pulling the "stable" branch, all intermediate commits from the "development" branch are pulled as well (because they're parent commits). But we're talking about binary files that don't have any sensible merging strategy (except theirs/ours), so the actual history of the files on the development branch is useless. When I pull the "stable" branch, I get this:

              X-------------------G stable
             /                   /
        a---b---c---d---e---f---g development
    

    Because G has a parent in the development branch, I get the whole history of the development branch (data objects for c, d, e, f and g) in my repository, which I'm not interested in (X is the same as b, with some file renaming applied).

    So I tried to git merge --squash changes from the development branch to the stable branch. The first such merge and commit went OK, the results were as expected (nice change log in the commit message, no relation to the development branch):

              X-------------------G stable
             /                   
        a---b---c---d---e---f---g development

    After I pull this squashed stable branch, I get this in my repository, which is what I want:

    a---b---X---G
    

    But the second merge failed (because git had no way to know how much I merged already and got confused).

    • Is it possible to somehow record the merge, without producing a "merge commit" with two parents?
    • Or, is it possible to tell git to merge only a certain "range" of revisions, like in SVN?
    • Or, is it possible to do a normal merge without having to download all refs from the other branch when pulling?
    • Or should I provide a custom merge driver for the files in question, that simply renames "their" version to "our", thereby resolving the conflicts? I'm still afraid that --squash will always try to merge the whole history, up to the common parent, solving only half of my problem.

    Update: rebasing

    If I understand rebasing correctly, I'll end up with this:

                                  X stable
                                 /
        a---b---c---d---e---f---g development
    

    Which gets me all the data I'm not interested in (c, d, e, f) and as a bonus, I'll loose the information that b was a stable version in the branch.

    Each development revision adds about 5MB to the repository size (and repacking the whole repo shrinks it only about 10%), the "stable" branch comes almost for free (the data is already there). I want pulling a single new revision from the stable branch to pull only the new 5MB, but instead updating from X to G downloads 25MB, because I'm somehow not able to say that I don't care about the contents of c, d, e and f.

    解决方案

    Starting with

          X stable
         /                   
    a---b---c---d---e---f---g development
    

    You can use the following steps to copy the last commit from your development branch to your stable branch:

    git checkout development@{0}  # get working tree from "development", detach HEAD
    git reset --soft stable  # reposition detached HEAD on "stable"
    git commit  # enter the appropriate commit message
    git branch temp  # create a temporary branch "temp" at HEAD
    git checkout temp  # get on the new temporary branch
    git branch -M stable  # rename "temp" to "stable"
    

    so you end up with:

          X-------------------G stable
         /                   
    a---b---c---d---e---f---g development
    

    If you continue work on "development", e.g.,

          X-------------------G stable
         /                   
    a---b---c---d---e---f---g---h---i---j development
    

    you can repeat the same git commands as above and you will end up with:

          X-------------------G-----------J stable
         /                   
    a---b---c---d---e---f---g---h---i---j development
    

    这篇关于Git重复合并压扁的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆