我发现自己,作为我工作流程的一部分,经常这样做:
- 我在一个分支上(我们称之为
topic
) - 我在
topic
上向CI发送一个提交,以便它被合并 - 我想做另一轮更改,所以我继续处理
topic
- CI同时将更改合并到
main
(在GitHub上,这意味着在我的情况下合并提交- GitHub显然不会在这里进行快进合并;见this answer) - 因此,我想回到更新后的
main
上,其中包含我一直在做的更改 - 我尝试检查
main
,它现在与topic
具有相同的 * 内容 *,但是 git
抱怨我的本地更改将被覆盖,因为我在本地修改了一些与前一次提交相同的文件,所以我必须:git stash
git checkout main
git fetch; git merge origin/main
- x1米11米1x
我知道git
命令有很多选项。有没有一种方法可以在一个步骤中完成上述四个步骤的过程,或者更少的步骤(除了编写脚本)?合并总是干净地应用,因为origin/main
和topic
在内容上是相同的(但不是git
历史)。
This unanswered question表示也许整个序列可以用git checkout -m
替换,对吗?
2条答案
按热度按时间dy2hfwbg1#
这个吗?
不过,它会变基而不是合并。
hgb9j2n62#
注意Benjamin W.'s answer比你要求的要好一点,因为它也可以处理你在
topic
上有任何新的提交,而这些提交还没有在main
上,除了你的未决更改。你正在做的合并 * 应该 * 总是快进,如果你还没有任何新的提交,那么rebase也是等价的。如果你在topic
上至少有一个新的提交,并且还有一些未决的更改,然后合并和变基会有所不同,但我倾向于在这种情况下变基个人主题分支。还要注意的是,当你直接转换到
origin/main
时,你甚至不需要main
的本地副本,这通常是正确的。甚至你的问题也可以省略git checkout main
步骤,因为你可以执行下一个命令,git merge origin/main
直接快进到topic
。由于这一点,实际上我建议删除你的本地main
副本,因为它几乎总是过时的。如果出于某种原因你再次需要它,你可以检查它,它将在那一刻是最新的。如果此时您希望以不同的名称(而不是
topic
)启动新分支,则可以发出以下命令:请注意,在您的问题中,如果您没有任何新的提交并且登陆了
main
并进行了未决更改,则创建新分支的命令将与上面相同。我想对rebase的--autostash选项发表一下评论。它确实是为你的工作流而存在的,但Git文档警告(强调我的):
在操作开始前自动创建一个临时的stash条目,并在操作结束后应用它。这意味着你可以在脏工作树上运行rebase。但是,请小心使用:成功的变基后的最终存储应用程序可能会导致不小的冲突。
这是隐藏通常是正确的,特别是当它后来应用到一个不同的提交时,而不是从它被隐藏。(看到其他人也被它咬了一口),随着时间的推移,我得出的结论是,使用提交比使用隐藏要容易得多,而且也更安全。我几乎只使用“wip”提交。如果你想尝试一下,对你的工作流程的调整是:
1.使用类似“wip:这里有一些信息”。
现在,您可以随时更新分支:
git pull --rebase origin main
#(或者,git fetch
后跟git rebase origin/main
)在rebase之后:
1.继续工作并在准备提交时修改wip提交,或者在变基之后:
git reset HEAD~1
,这将使您的更改返回为挂起。与stashing和popping相比,这种方式最大的优点是,如果现在或以后出现问题,你可以很容易地返回到提交。一般来说,我也建议尽早提交,经常使用多个wip提交,然后在完成后将其压缩为几个完美的提交。