个人中心
文章发布
退出
作者热门文章
- c - 在位数组中找到第一个零
- linux - Unix 显示有关匹配两种模式之一的文件的信息
- 正则表达式替换多个文件
- linux - 隐藏来自 xtrace 的命令
28
4
我从 master 分支创建了一个功能分支。之后有来自功能分支的提交 [F1]。
[F1] -- Feature Branch
/
[M1]-[M2] -- Master Branch
之后feature分支 merge 到master分支，master分支又多了两个commit[M3]和[M4]。
[F1] -- Feature Branch
/ \
[M1]-[M2]-[F1]-[M3]-[M4] -- Master Branch
现在我又向功能分支添加了两个提交。
[F1]-[F2]-[F3] -- Feature Branch
/ \
[M1]-[M2]-[F1]-[M3]-[M4] -- Master Branch
这个时候，我是先把feature分支rebase到master分支，让feature分支有[M3]和[M4]提交的变化，还是直接git merge。
此外，如果我先执行 git rebase，[F1] 提交不会在两个分支中:
[F1]-[F2]-[F3] -- Feature Branch
/
[M1]-[M2]-[F1]-[M3]-[M4] -- Master Branch
最佳答案
所以如果您还没有对 master 进行更改并且您不介意重写 master ，有一种方法可以做到这一点——但是当你 rebase 时，你就是在重写历史，所以make sure you know what you are doing first .
如果你确定这是你想要的历史方向，你应该首先检查 master 分支并以交互方式将它 rebase ( git rebase -i ) 到 所在的提交功能 已从(在您的情况下为 [M2] )中删除。
在你 rebase 之前，你的历史应该是这样的(根据你原来的问题):
[F1]-[F2]-[F3] -- Feature Branch
/ \
[M1]-[M2]-[F1]-[M3]-[M4] -- Master Branch
启动交互式 rebase 后，您应该会看到以下操作:
pick hash_f1 [F1]
pick hash_m3 [M3]
pick hash_m4 [M4]
您将希望删除第一个提交，feature 的 merge 内容在提交之前 [F2]和 [F3] ，以便 master 可以不重放更改 [F1]在里面。请注意，您不会丢失 [F1]提交，因为它仍将存在于功能的历史记录中。
rebase 应该给你这个历史:
[F1]-[F2]-[F3] -- Feature Branch
/
[M1]-[M2]-[M3]-[M4] -- Master Branch
master 拥有所有 M提交，并且 feature 拥有所有 F提交，仍然从 [M2] 中删除.从那里可以通过简单的 merge 将 feature 返回到 master 中:
git merge --no-ff feature
瞧——你已经得到了你想要的:
[F1]-[F2]-[F3] -- Feature Branch
/ \
[M1]-[M2]-[M3]-[M4]-[F*] -- Master Branch
再次强调，这就是您想要做的，请务必小心，因为重写历史可能很危险。也就是说，在本地进行绝对值得。
此外，这个过程可以扩展到任何 refs，而不仅仅是一个特性和主分支，所以在其他情况下这可能更有意义。在我看来，像master这样稳定的分支一般是不能改写历史的，但是每个Git环境和工作流都不一样，所以真的没有不能改写的规则。
关于git rebase 已经 merge 了分支？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/34873081/
28
4
0
替换双
所以通常当我使用 IDA 调试时我不会遇到任何问题；然而，对于这个特定的进程(模块之前的大小为 9.9 MB)，IDA 坚持每次启动该进程时都会重新设置基准，这会卡住 IDA 并迫使我在它真正启动之前
在 git rebase -i 的正常过程中看起来像这样(=> 表示终端命令提示符): => git logg * 7bec976 (HEAD -> develop, origin/develop)
我正在用几个分支尝试一些东西，所以我重新基于一个临时分支并且在解决一些冲突时我决定不以另一种方式完成重新设置它。然后我删除了涉及的临时分支并继续我的快乐方式。几个小时后，我想 rebase 另一个分支
我有一个本地分支机构，我们称它为 DEV。分支提交历史如下所示: module_A: 添加CRC校验(9273467932) module_B:更改关机程序 (84705723) merge 来自 X
是否有任何常见的 git 使用错误或一般的任何原因，如果这些冲突已在先前的 rebase 中全部解决， rebase 会重复来自先前 rebase 的冲突？ 此外，rebase 是否优先于如何解决冲突
我们遇到了一个问题，如果你rebase你的分支在master之上然后push，另一个在你的分支上工作的人pull s 和 gets 各种合并冲突，因为 rebase 重写了历史并且提交与分支上的提交不
我们遇到了一个问题，如果你rebase你的分支在master之上然后push，另一个在你的分支上工作的人pull s 和 gets 各种合并冲突，因为 rebase 重写了历史并且提交与分支上的提交不
我注意到如果我做一个 git rebase -i HEAD~10 然后不要更改结果文件中的任何内容，仍然会执行某种 rebase 。 IE。我需要 git push origin branch --f
场景: 我正在与一个 20 多人的团队一起开发远程 git 存储库。经常创建、提交和 merge 分支以掌握。 我和一位同事在一个分支机构一起工作了几天。他重新定位分支，解决所有冲突并 push 。
出于某种原因，运行 git rebase 突然没有 rebase 我的整个分支，我无法想象为什么。在 rebase 之前我有以下内容: 运行 git rebase develop 后我得到的是: 请注
我的 git 分支看起来像这样: master-*-*-*-*-*-*-implement_x \ \-*-further_foo_fixes_that_dep
人们常说，您不应该对已经推送的提交进行 rebase 。那是什么意思？ 最佳答案 要理解这一点，我们需要了解一下 git 的工作原理。 git 存储库是一个树结构，其中树的节点是提交。这是一个非常简单
在过去的几天里，我一直在研究使用 Git 进行 rebase 。大多数支持 rebase 的论点都说它清理了历史并使其更加线性。如果你进行普通 merge (例如)，你会得到一个历史记录，显示历史记录
最近，我在更改提交消息的同时对仅限本地的存储库进行 rebase 取得了很大的成功，之后只有提交消息被更改，但历史本身没有。 现在我有了自己的存储库 - 远程和本地。我在几个分支上做了几次提交并且已经
我在我的功能分支 my-feature ，我运行 rebase develop 分支: (my-feature)$ git rebase develop 终端显示一堆冲突，在detached现在模式:
总结 在当前分支中找到还包含在任何其他分支中的最新提交的最快方法是什么？ 奖励:该技术能否允许上述问题中的“任何其他分支”成为“任何其他远程分支”或“任何其他本地分支”？ 背景 我喜欢使用 git r
interactive rebase 有什么不同，比如: git rebase -i HEAD~3 并且在没有 -i 的情况下 rebase : git rebase HEAD~3 最佳答案 正如 T
这是我在重新设置当前分支的基础同时防止本地分支变平时通常做的事情: git fetch origin git rebase -r origin/develop -r 是 --rebase-merges
我正在同时处理两个功能，“feature1”是“feature2”的基础。我为他们创建了两个分支；当我在 feature1 上工作时，我提交到“feature1”分支；当我在 feature2 上工作
当我读到 git-rebase 时，我知道重新设置的提交应该丢失。我说应该是因为我注意到，知道 rebased 提交 sha，我可以记忆起它。 假设我有以下三个提交 A -> B -> C C 的 s
我是一名优秀的程序员,十分优秀！