gpt4 book ai didi

git - 如何重写 git 历史以匹配流行的 git 工作流程

转载 作者:太空狗 更新时间:2023-10-29 13:47:13 27 4
gpt4 key购买 nike

我的大部分 master 分支看起来像一个链表而不是树。也就是说,我所做的大多数 merge 都是快进 merge 。我想我会跟着"A successful Git branching model"工作流,它指示我避免快进 merge ,而是留下我的特征和特征分支连接的轨迹。假设这是个好主意。

如何最轻松地重做我的树?

即说我有这种日志:

* hash1 great feature #1 - almost done
* hash2 side work
* hash3 side work
* hash4 great feature #1 - added y
* hash5 great feature #1 - added x
* hash6 documentation - added more docs
* hash7 documentation - removed stuff
* hash8 project-wide: added deployment descriptors....

我想要这种日志(或任何类似版本):

* merged side work into branch develop
|\
* * hash2 (feature branch) side work
* * hash3 (feature branch) side work
|/
* merged great feature into branch develop
|\
* * hash1 (feature branch) great feature #1 - almost done
* * hash4 (feature branch) great feature #1 - added y
* * hash5 (feature branch) great feature #1 - added x
|/
* merged documentation into branch develop
|\
| * hash6 (feature branch) documentation - added more docs
| * hash7 (feature branch) documentation - removed stuff
|/
* hash8 project-wide (develop branch): added deployment descriptors....

我有 40 多个提交,我的树比我在这里展示的要困惑得多,因此从 init 创建一个新分支并挑选单个提交是最痛苦的。我想 rebase --interactive 可能会有所帮助,但我不确定它是否会。 rebase 使树变平,我需要把它变大。我已经展示了将 feature 分支 merge 到 develop 中,但我也可能在某些时候将 develop 分支 merge 到 master 中。怎么办?

最佳答案

正如你所说,首先你没有那么多的提交,所以你可以做的是重写你的历史,问题是你必须在最后推送 --force。

git rebase HEAD~40 -i

然后在这里您可以通过将 pick 更改为 s(将 2 个提交 merge 在一起)来压缩,并通过更改 来编辑您的提交消息选择e

正如您再次提到的其他解决方案,历史只是历史,您可以跟踪以前的“工作流程”并随时开始新的“工作流程”。您将保留真实的历史,即使它并不完美。

IMO,尽可能多地压缩,编辑一下您的历史记录,然后开始您的新工作流程。

关于git - 如何重写 git 历史以匹配流行的 git 工作流程,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/21246447/

27 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com