Question

所以我通常在git中创建一个功能分支，处理它，然后与主（主干）分支合并。

我创建了一个功能分支，但我最终并没有合并到master中。

现在主分支已经持续了几周/几个月，现在我想再次使用该功能分支，但我想用主分支中的任何内容更新它。

功能分支是所有新文件，因此应该存在任何合并冲突。

我该怎么做呢？

注意：我希望此代码保留在分支上，以防我不想再次合并它，因为这是一个重大变化。

如果你能解释它背后的理论，那么我就能理解这将是伟大的。

Answer 1

签出您的功能分支，并将master合并到功能分支（git merge master），或者在master（git rebase master）之上重新设置功能分支。

您选择哪一个取决于您希望历史记录的样子。

如果合并，旧的提交将继续以原始状态存在于旧版本的master之上，新的合并提交包含您的更改和新版本的master。有些人喜欢这样，因为它准确地反映了原始历史，并且因为它产生的冲突少于rebase。但是，这种做法可能会在很多合并提交中产生令人困惑的历史记录。 “git bisect”命令对于具有大量合并的历史记录也很糟糕。

如果您使用rebase，您将在新的主版本之上进行一系列提交，并且您将丢失原始提交。这创建了一个简单，线性的历史。您还可以使用'git rebase -i'在发布或将其添加到master之前清理您的提交（如果您选择这样做）。因为必须为每个提交解决冲突，而不是仅仅为合并提交解决一次，否则引用会产生更多冲突。

我更喜欢重新定义我尚未发布的代码，并且仅在我真正需要历史记录时合并以显示并行发生在两个位置的开发（例如我已经分叉和修改的项目，而不打算向上游发送我的更改;然后我将不时合并上游的更改。

Answer 2

文森特所说的是对的，我也会建议你改变。

原因是当您最终将您的功能合并到master时，开发历史记录看起来是合乎逻辑的。例如：

last_master_commit_before_feature_merge
feature_commit1
feature_commit2
...
last_feature_commit   <-master

这意味着，例如，如果您的某个功能提交创建了一个错误，则更容易回顾历史记录并确定执行的提交，而不会在历史记录中跟踪一堆合并。 This page应提供有关变基的更多信息。

如果选择重新绑定，请在执行以下操作之前创建备份分支：

git checkout my_feature_branch
git branch backup_branch
git rebase master

这是因为如果出现任何可怕的错误，你需要点击重置按钮，你可以。

如何从trunk中的代码更新旧分支？

2 个答案: