我正在尝试比较 Bitbucket 上的 dev 和 master 分支。不幸的是,Bitbucket 似乎使用提交来进行比较,而不是分支的实际状态。因此,如果我提交了 dev,然后为 master 创建了一个不同的分支,然后直接合并到 master,Bitbucket 会看到差异,尽管实际上没有差异。这真令人沮丧。
是否可以看到两个分支之间的实际差异?如果不在 Bitbucket 中,那么在 Jetbrains 或 VSCode 中,如果没有,那么至少在 git 本身中?
我觉得我必须让两个分支都有共同的提交。这里合并或变基合适吗?
我认为你遇到的是流程问题,而不是工具问题。
你的问题不太清楚。我的假设是,您正在使用 2 个生命周期分支,
dev
和 master
,其中 dev
在战略时间段(例如冲刺)内领先于 master
。有了这个,我听说您对 dev
进行了更改并推送,然后从 master
分支(称之为 feat/123
),并在合并回 master
之前进行了相同的更改。
如果是这种情况,那么您的更改虽然内容相同,但会被跟踪为不同的提交哈希,因此 git 会将它们显示为差异。
如果您希望最终结果是
dev
和 master
没有显示差异,我建议您先从 master
切下分支(再次称为 feat/123
),然后在那里进行更改。然后,您可以自由地将 feat/123
合并到 master
(例如修补程序),也可以按照您认为合适的顺序合并到 dev
(我们的组织将首先合并到 dev
,并在合并到 之前测试那里的更改) main
)。
这样,您可以进行一次更改并合并两次,以便将准确的提交放入目标分支中。这将防止
master
和 dev
分支之间出现不需要的差异。
我建议您在使用
cherry-pick
或 rebase
等命令之前先清楚了解它们的用途。 Git 文档和 StackOverflow 非常适合这一点。在 cherry-pick
分支和目标之间使用 rebase
或 feat/123
将导致您当前的情况,因为这些操作将新的提交写入树。
如果您需要完成当前情况,以便删除具有相同内容的差异,我建议只需将提交恢复到
dev
,然后将从 feat/123
剪切的 master
分支合并到 dev
。