我正在尝试重新组织GIT存储库,它充满了无组织的分支。现在我们想在那里建立一些结构(开发,生产,功能,...分支),并删除/压缩许多小的变化。但是有些东西需要保持原样,因为有人正在努力。
因此,我创造了一个庞大的结构,将旧事物压缩在一起(没有人对几年前的小错误修复感兴趣)并且基本上修复了今年开始的一切。
但是现在问题来了 - 一些分支是活动的,不能被完全压扁,无法删除/移动(直到新模式证明工作一段时间)并且内部包含很多小合并,如下所示:
jacks_branch
A-B-C-F-G-H-I-J-M-N-O-P ...
\D-E/ \K-L/
我想在相应的功能分支上复制此内容,例如
feature_123
XX-YY
=>
XX-YY-C'-F'-G'-H'-I'-J'-M'-N'-O'-P' ...
\D'-E'/ \K'-L'/
(架构更复杂,这是有问题的部分)
我想做点什么
git checkout feature_123
git cherry-pick C..P
但是它导致所有这些合并的冲突
error: could not apply E
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'
I
提交(合并)解决了所有这些冲突,但它没有应用并且采摘樱桃
最好的出路是什么(除了从一开始就把它组织得很好)?
编辑 - 添加了示例:
我有
* 3b0a2b4 3.line Adam (HEAD, Adam)
* c04efb0 Just fixed merge from other computer
|\
| * 3e5f111 2.line Adam_a
* | 897bfc3 2.line Adam_b
|/
* 308a3c5 1.line Adam
* 33f3119 === new year ==== (master)
* 436619b 1000.line
.............
* 0a12c01 4.line
* 41d763d 3.line
* dd1feb0 2.line
* 55aa2c2 1.line
* 84b12e9 Point zero
请注意,分支Adam
中存在冲突(3e5f111和897bfc3分别将行Adam_a
和Adam_b
添加到同一位置),开发人员Adam在c04efb0中解决了这个问题(通过写一些完全不同的东西,比如Adam_* # it does not matter
左右)
我希望添加新分支develop
- 这可以轻松压制master
* 75675e1 === new_year === squashed 1.000 lines (HEAD, develop)
* 84b12e9 Point zero
现在我想添加分支feature_1
(在develop
上)来自Adam
的内容(但不必手动解决所有已经解决的冲突,我想要合并(4444567) )与分支Adam
)
* 555567 3.line Adam (HEAD, feature_1)
* 4444567 Just fixed merge from other computer
|\
| * 3334567 2.line Adam_a
* | 2234567 2.line Adam_b
|/
* 1234567 1.line Adam
* 75675e1 === new_year === squashed 1.000 lines (develop)
* 84b12e9 Point zero
得到这个:
* 555567 3.line Adam (HEAD, feature_1)
* 4444567 Just fixed merge from other computer
|\
| * 3334567 2.line Adam_a
* | 2234567 2.line Adam_b
|/
* 1234567 1.line Adam
* 75675e1 === new_year === squashed 1.000 lines (develop)
| * 3b0a2b4 3.line Adam (Adam)
| * c04efb0 Just fixed merge from other computer
| |\
| | * 3e5f111 2.line Adam_a (Adam_a)
| * | 897bfc3 2.line Adam
| |/
| * 308a3c5 1.line Adam
| * 33f3119 === new year ==== (master)
| * 436619b 1000.line
| * 0a12c01 4.line
| * 41d763d 3.line
| * dd1feb0 2.line
| * 55aa2c2 1.line
|/
* 84b12e9 Point zero
(稍后我会删除Adam
和master
)
答案 0 :(得分:1)
我认为,您(以及您的团队)应该将现在重点放在您想要使用的工作流程上,而不是尝试重写历史记录。这让我想到了下一点,即如果你继续使用特定的git工作流,而团队的其他成员继续使用你当前的那个,那么你可能不会成功。
假设您的存储库中的各个分支没有太多分歧,您和您的团队应该开始合并并整合到您希望存储库看起来的任何内容,例如:主分支和功能分支。
重写历史记录(例如使用rebase)很棘手,因为这意味着自从您修改或压缩之后的每次提交也必须被重写,这意味着这些提交的新版本不再与其他人匹配&# 39; s&#34; old&#34;版本。在最近的历史中谨慎使用时,它可能很有用,但是重写整个存储库的历史记录并希望将其与主动开发协调一致并不是我想要的。