我的团队使用git和Bitbucket进行版本控制。
我之前已经从我的存储库的一个分支创建了一个Pull请求到该团队主存储库的一个分支。
此拉取请求已被接受，我的分支已合并。
昨天我在我的存储库中为同一个分支添加了一些更改。当我尝试向团队存储库中的同一分支创建拉取请求时，我收到了一些合并冲突的通知。
我查看了团队分支的提交日志，并意识到尽管提交消息，作者（我）＆amp;日期相同，远程分支中的提交ID不同。
这可能是什么问题？
我的印象是即使在合并提交ID之后也会保留。
还有其他原因造成这种情况吗？
P.S。
我已经读过cherry-pick可以更改提交ID。有什么想法吗？
答案 0 :(得分：4)
合并既不保留也不保留commit-ID。合并make new 提交（假设你这样做是为了避免“快进”操作）。
也就是说，给定一系列单独的提交，我将使用单个字母标记：
A - B - C
\
D
commit C（可能真的可能是ID 6da748a...）已提交其父级B，而提交D（也许实际上是740c281...）也有提交B作为其父级。要合并这两个提交，git必须使用两个父项创建一个新提交：
A - B - C - M
\ /
D
此新提交M具有与其他每个提交不同的ID，但提交D完全不变，因此仍具有相同的ID（740c281...）。
许多人试图避免进行这种相对微不足道的合并。他们不是将他们的工作（提交C）和你的工作（提交D）并进行新的合并提交，而是制作提交消息的副本 - 包括作者和日期 - 并进行相同的更改致C的{{1}}。这个操作确实被称为“樱桃挑选”（以及“变基”），但它使用一个新的，不同的commit-ID进行一个新的，不同的提交，我们称之为B：
D'原始A - B - C - D'
与此新D之间最明显的区别是D'已提交D'作为其父级，而不是提交C。 （在正常情况下，它也有不同的树内容，因为您B - 到 - B更改已应用于文件D中所见的文件，这些更改在某些地方可能与C中的那些。）
但是，提交B不是合并提交。 （合并提交是具有至少两个父提交的任何提交。使用D'或git log --graph或其他一些图形查看器可以更直接地查看提交图。）
如果您的工作被重新定位（或挑选）到上游，并且您获取然后尝试合并上游，git有时（但不总是）能够检测到重复并自动清理。当它无法自动检测重复时，您几乎总会遇到各种合并冲突：git看到您尝试更改某些代码（在上例中的提交gitk中），并且他们尝试更改相同的代码，但是以稍微不同的方式（在上面的提交D中）。出于这个原因，改变其他人的代码一般不被认为是非常有礼貌的：相反，上游倾向于要求你自己重新设置代码（虽然它仍然是私有的），然后他们可以将它包含为“快进”（合并） - 免费）添加到他们的存储库。
（这样你也可以自己进行rebase操作所需的任何更改。例如，如果你修复了版本D'中的一个错误，他们也修复了D，但你和他们采取了不同的方法，你可以解决这个冲突 - 可能比他们更容易解决，因为你知道你做了什么，为什么你这样做，以及你的新功能是否依赖于你的版本的修复。）