pick 222 commit to be stashed
pick 111 commit to be pushed to remote
# Rebase 111..222 onto 333
#
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but discard this commit's log message
# x, exec = run command (the rest of the line) using shell
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out
重新排列这两个提交(它们被列在最旧的=〉最新的),如下所示:
pick 111 commit to be pushed to remote
pick 222 commit to be stashed
7条答案
按热度按时间brccelvz1#
如果你还没有将任何一个提交推送到你的远程仓库,你可以使用交互式重定基来“重新排序”你的提交,并且只隐藏(新的)最近提交的更改。
假设你已经 checkout 了当前分支的提示(在你的例子中是commit 111),执行下面的代码:
这将打开你的默认编辑器,列出最近的两次提交,并提供一些说明。在这里你要非常小心,因为你将有效地“重写”仓库的历史,如果你不小心的话,可能会丢失工作(如果需要的话,先备份整个仓库)。我估计了提交的哈希/标题如下
重新排列这两个提交(它们被列在最旧的=〉最新的),如下所示:
保存并退出,此时git会重写你修改过的两个提交。假设没有问题,你应该已经颠倒了两个变更集的顺序。这可以用
git log --oneline -5
来确认,它会先输出最新的。此时,您可以简单地对最近的提交进行软重置,并隐藏您的工作更改:
需要特别指出的是,只有在您之前没有将这些更改推送到远程数据库的情况下,此选项才是真正可行的,否则它可能会给使用存储库的每个人带来问题。
idv4meu82#
如果是我,我会避免任何有风险的修订编辑,并执行以下操作:
1.在提交222的SHA上创建一个新分支,基本上作为书签。
1.切换回主分支,在其中,还原提交222。
1.推送所有已执行的提交,这只会推送提交111,因为222已恢复。
1.如果需要的话,从第一步开始处理分支。根据需要将 Backbone.js 合并到分支上,以保持它的最新状态。我不会为stash而烦恼。
当提交222中的改变进入时,该分支可以合并到 Backbone.js 。
bgibtngc3#
另一种解决方案是使用隐藏:
之前:
1.git重置head~1〈--- head移位一位回到c222;工作中仍包含c111变更
1.git stash push -m“commit 111”〈---暂存/工作(包含c111更改)被隐藏;分段/工作回滚到修订的标题(包含c222变更)
1.git重置head~1〈--- head移位一位回到c333;工作中仍包含c222变更
1.git stash push -m“commit 222”〈---暂存/工作(包含c222更改)被隐藏;分段/工作回滚到修订的标题(包含c333更改)
1.git stash pop stash@{1}〈---最旧的stash条目,其中c111更改已删除并应用于暂存/工作
1.git commit -am“commit 111”〈--包含c111更改的新提交成为新的头文件
注意如果不指定stash@{1}条目,则无法运行“git stash pop”。stash是LIFO堆栈--而不是FIFO --因此将错误地弹出包含c222的更改的stash@{0}条目(而不是包含c111的更改的stash@{1})。
注意如果提交111和222之间存在冲突的块,那么在尝试弹出时,您将被迫解决它们。(如果您也使用了替代的重定基解决方案,就会出现这种情况。
之后:
irtuqstp4#
在Git中,通常有很多方法可以剥这只猫的皮,但因为我们讨论的是2次提交(而不是多次),所以在阅读这个问题时,最简单的想法是:
这个问题问的是如何隐藏上一次提交,但我认为在正常情况下,你已经完成了推动所需提交的目标,所以你不需要再这样做了。因此,你可以继续你的开发。但如果你仍然想隐藏你的顶级提交,你可以继续:
注意:这比交互式的重定基(稍微)容易的原因是因为只有两个提交需要进行cherry pick,而您可能希望在它们之间进行推送。
ki0zmccv5#
这对我很管用;
1.在提交时 checkout 当前分支的起点。
1.从此提交创建新分支。
1.合并具有代码的分支,以便在新分支中存放。
1.在新分支中进行软重置。
1.隐藏目标代码。
1.移除新分支。
我建议使用类似于SourceTree的东西。
vqlkdk9b6#
我解解陈言:
删除目标提交
Git还原--策略解析222
将提交222保存到补丁文件
222.补丁程序
将此补丁程序应用于取消登台
修补程序-p1〈222。修补程序
推到存储区
git隐藏
删除临时文件
rm -f 222.修补程序
在我看来非常简单的策略
nr7wwzry7#
就我个人而言,我发现这些答案大多令人困惑,所以我会做的是:
这将撤消来自111和222的更改,它们也不会被暂存。然后,您可以暂存您想要的更改,当您准备好时,隐藏其余的更改,并提交。然后,您可以隐藏弹出您的更改,并提交它们。