git - 将git分支分成多个分支 merge 到master

标签 git branch branching-and-merging

我的团队一直在 master 的原型(prototype)分支中工作。我现在想接受这项工作,将其分成不同的“功能分支”,然后将它们单独 merge 到 master 中。我看到有几种方法可以做到这一点,但我都不喜欢:

1 - 从 ma​​ster 创建一个新分支 Feature_1。手动将代码从 Prototype 复制到 Feature_1。这意味着我在制作 Feature_N 时必须跟踪复制的内容,但我会丢失历史记录。

2 - 从 Prototype 创建一个新分支 Feature_1。以某种方式还原不属于 Feature_1 中第一个功能的代码。这避免了对 git 撒谎(并保留历史记录),但感觉 Feature_N merge 起来会一团糟,因为我会告诉主人,当我推送 Feature_1 时,更改已恢复。

我是否缺少更好的方法来做到这一点?

最佳答案

如果您的提交是不与任何其他功能的提交共享依赖关系的单一功能提交,@Michael 的回答是个好东西。但是,如果您在任何提交中混合使用这两个功能,您将需要 interactive rebase .它允许您任意重新分配更改 block 和提交边界,并且它确实跟踪哪些 block 尚未提交到当前分支。

如果功能更改有时只是 merge 到提交中并且没有交叉功能依赖性,为了让生活更轻松,我的第一个尝试是 git rebase -i master prototype,将提交拆分为将大块头混合成两个提交,每个提交一个,然后像迈克尔的回答一样以 cherry-pick 结束。给定

A1-B2-C12-D2-E1-F12    prototype

其中数字表示提交包含哪些功能的代码,对于 `git rebase -i master prototype 你要编辑提交 C12 和 F12,

pick A1
pick B2
edit C12
pick D2
pick E1
edit F12

(在这里使用每个提交的散列而不是它的说明性标签)。

Rebase 将在提交 C12 后停止,您可以 git reset HEAD~ 然后 git add --patch 应用所有功能- 1 hunks,git commitC12 所在的位置创建提交 C1,然后 git commit -a 应用所有剩余的帅哥并在其后创建提交 C2。你最终会得到

A1-B1-C1-C2-D2-E1-F1-F2

然后你可以 git checkout -b feature1 master; git cherry-pick A1 B1 C1 E1 F1 和 feature2 类似。

在更复杂的情况下,此方法仍然仅需非常小的更改即可工作。 Interactive rebase 比上面可能让你相信的要好得多,但到目前为止,最好的了解方式是坐下来与 the manpage 交谈。当您进入那里并争夺一些帅哥的乐趣时。这样做,可能很快就会达到这样的程度:将此作为出版前的仪式通常比尝试让您的实际工作流程在每一个小步骤都保持可发布更方便。

关于git - 将git分支分成多个分支 merge 到master,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/26657309/

相关文章:

branch - Perforce,如何将更改集成到另一个分支?

Git fetch 说 "success"但没有下载任何东西

git - 从远程仓库中检索丢失的文件?

当 merge A->B 然后 B->A 时,Git 不会产生新的提交,我如何确保其他团队看到第二次 merge ?

git - merge 后如何跟踪提交的来源?

SVN分支比较

azure-devops - Azure Devops 拉取请求 - 如果用户在分支机构工作过,则阻止用户批准请求

git - 如何配置 git 在一个 'remote' 中从 http pull 并通过 ssh 推送?

branch - Gitflow 功能与 bugfix 分支命名

algorithm - 重写 if 语句以避免分支是否值得?