从git svn线性层次结构生成git树,主题中包含标签

时间:2016-01-11 09:58:07

标签: git svn version-control merge git-svn

所以我有一个问题,我猜这个问题对于从svn迁移到git的人来说很常见,我希望有人写了一个脚本来解决它,所以我不会这样做。必须。

因此,当我们使用svn作为我们的主要回购时,分支/标记更加昂贵,因此我们有3个分支,开发,qa和生产,并标记每个生产版本。因此,在日常开发中,jira门票已经在当前的开发负责人身上进行了工作,并致力于以标题开头的JIRA:ABC-123'其中ABC-123标识票证,其中ABC是功能分组,123是票号。在我们的模型中,来自开发的功能元素将合并到qa中进行测试(开发中的战术提交,在qa中成为更大的战略提交),并且将这些策略提交的错误修复添加回开发之前,然后合并到& #39;发布分支'这是他们合并回qa然后生产。

开发的git svn克隆已经(正确地)创建了从开发分支返回的单个长链提交。

但是,我想重组一下,以便将所有各种模块提交分成多个分支,这些分支会定期合并回开发中,这样我就可以回过头来找到一个点。在开发分支历史中,这是当前的qa,生产和开发分支所共有的,我可以从中重建qa和生产分支,这应该基本上是开发少数几个功能分支。

我手动回去大约一个月,通过手动将开发分支中的文件与qa分支进行比较,还原票并将我所获得的内容与我们创建的提交进行比较,但差异只是太大了,因为git可以生成有意义的自动合并。我怀疑我的问题是在11月/ 12月的模块A中有积极的开发从dev进入qa并且因此被释放,而模块B也在开发时开发,但不是qa / prod,所以我需要从origin / master中删除A和B以创建一个共同的祖先,这样我就可以在A生成qa或A和B中添加回到当前的开发分支。

现在我接受将需要一定程度的手动冲突解决方案,其中A和B显然在不同区域提交,碰巧改变了相同的文件,但我希望git可以应对大多数事情。我发现在大多数情况下,当我忽略空格时,差异就可以分开,只要它们按顺序完成即可。

我怀疑我需要使用git log --date-order --date=iso --format=:format:%H\ %cd\ %s来生成我可以读取的内容,并从该脚本生成指令,将所有提交拆分为模块分支,从公共点开始,但花了2天时间这已经是,所以我希望其他人已经解决了这个问题。如果没有,我只需要自己解决,并在此处发布解决方案,以便下一个人可以使用它: - )

修改

所以看看git rebase,我想也许图表可能会有所帮助: -

我想我现在拥有的是这样的(下面是故障单模块/数字)

A---------B---------C---------D---------E---------F---------G
ABC-123   DEF-111   GHI-165   ABC-124   DEF-111   DEF-112   GHI-166

我理想的是

 C'--------G'
 GHI-165   GHI-166
/
A---------D'
ABC-123   ABC-124
\
 B---------E'--------F'
 DEF-111   DEF-111   DEF-112

最终

 C'--------G'
 GHI-165   GHI-166
/
A---------D'
ABC-123   ABC-124
\
 B---------E'
 DEF-111   DEF-111
 \
  F'
  DEF-112

这样我就可以创建一个基于A(ABC-123)的生产分支,它只包含B --- E'分支机构(DEF-111机票)

1 个答案:

答案 0 :(得分:1)

git rebase --interactive可能是你在这个混乱任务中的主要工具。您也可以迭代地进行拆分,例如开始特定行的rebase,选择修订(根据我猜的评论);当出现太多冲突时 - git rebase --abort并尝试以更小,更容易管理的块来重新整理历史记录。

修改,例如,要从您提供的C-G行中获取第一个分支development,您可以执行以下操作:

git checkout -b branchCG
git rebase -i A 
#remove all the commits except for C and G
#resolve possible conflicts
#at the end you have your C' and G' in constituting branchCG

现在我们想要清理原始分支,不是绝对必要的,但可以方便地避免混乱历史悠久

git checkout development
git rebase -i A
#remove/comment-out only the commits that you have picked for the branchCG
#resolve possible conflicts

此时你的开发没有branchCG的内容,你可以继续下一个分支。

离开B作为E'的父母。和F'您可以将它用作基点而不是A,或者在执行两个rebase时保留未注释。如果您在B之前进行了更改,则后一个选项可能无效。