我和饭桶陷入了困境。
设置如下：
我们有主创、舞台和特色分支。我们使用的是合并策略，没有压缩。我们同时实现了多个特性，并将它们合并到舞台分支。每隔几天，我们都会将所有内容合并到master并部署到生产环境。
但是在生产上出现了一个问题，我们不得不在master上恢复更改。所以现在master没有任何包含在stage的最新合并中的更改。
我们目前的做法是：
1.为每个功能创建修补程序分支
- cherry pick commits from original feature分支
1.将其直接合并到master。
我对一个长期存在的分支有一个问题（不要问我们是如何来到这里的）。基本上有一个分支，其中有一堆提交是在几周内创建的（但大多数是在一周内）。现在我正试图弄清楚如何将此提交选择到hotfix分支。但问题是，这个特性分支还包括来自stage的合并提交。所以一切都是一团糟。
我试过几种方法。我知道该特性分支上第一次和最后一次提交的哈希值。所以我试着这样做：git cherry-pick <hash-first>^..<hash-last>
但它不起作用。它似乎试图应用不相关的提交（我猜这是因为从阶段到功能分支的合并）。在解决冲突后，它只添加一个带有不相关更改的提交。我不知道发生了什么事。
我也试着只提供一个分支的名称：git cherry-pick ..<branch_name>
但它是说error: empty commit set passed我试图调查
我试着把我的功能分支的副本重基到主分支上。所以我 checkout 了特性分支，创建了一个新的分支，并试图将其转换到主分支上。但它似乎什么也没做。
我现在唯一的想法是一次通过每个提交，然后选择它。但这将产生大量的工作和解决合并冲突.而且可能会在舞台和大师之间产生差异。有更好的办法吗？
我使用Linux（使用WSL）。
2条答案
按热度按时间xcitsw881#
假设
feature分支上的第一个黑色提交点可以被命名为F1。stage之前的最后一个黑色提交点可以被命名为F9。main上的红色回复提交点可以命名为M3。stage上的灰色提交是S1，S2和S3。然后你可以通过运行以下命令将所有来自
feature的提交重新引入到main中（也称为“cherry-picks分支”）：(you也可以使用
--onto main代替--onto M3）F1^表示F1的父代，因为rebase语法是--onto <target_commit> <start_commit_NOT_including> <branch_to_rebase>。上面的rebase基本上与cherry-pick F1到F9以及cherry-pick S1到S3相同，因为默认情况下rebase会展平版本历史。你也可以使用
--rebase-merges1选项来“保留”来自stage的合并提交。我把preserve放在引号里，因为它不会像重用原来的合并提交那样保留，它会创建新的、重定基的提交。但是合并结构应该保持不变（尽管如果合并中存在在原始合并中手动解决的冲突，则需要再次手动解决它们（这是首选rebase而不是merge的另一个原因，因为这样就不会出现问题））。
与上述合并相关的潜在冲突当然也会出现在纯粹的cherry-pick方法中，所以如果你遇到冲突，你会以一种或另一种方式遇到冲突（尽管你通常会更好地从rebase/cherry-pick中获得多个较小的冲突，而不是从merge中获得一个大的冲突）。
1 E.g
git rebase --rebase-merges --onto M3 F1^ reintroduce_feature_commitsvq8itlhq2#
-i将带您进入交互模式。你会看到一个给定范围内的提交列表。
选择并删除那些你不想选择的提交行。
保存并关闭。
(If编辑器显示为“Vim”，然后按
dd将删除一行。输入:wq[enter]将保存并退出）