我的公司在 bitbucket - Git 上托管代码。我们的工作方式是为每个问题创建分支，个人在该分支上工作。工作完成后，他提出 merge 请求。在提高 PR 之前，他使用 master 分支对代码进行了 rebase。团队中的其他人审查他的 PR，然后批准它。一旦 PR 批准，同一个人将其 merge 到 master 分支

我在 6 月 2 日创建了分支，6 月 14 日 merge 了 PR。 Branch 在 3 个不同的文件中有 3 个提交。随后其他开发商的分支机构于 6 月 26 日 merge 。他还处理 2 个文件，我更改了这些文件。现在一个多月后，当我检查文件历史记录时，我在那里看不到我的提交。在我更改的 3 个文件中，只有 1 个文件更改存在并且它们显示正确的提交编号。其他 2 次提交未显示在文件历史记录中。我可以猜到，我的更改已被覆盖，但文件的 git 历史记录必须显示提交。

有没有人知道它是如何发生的。我的意思是 git 历史记录中特定文件的提交是如何消失的。

谢谢 阿尼卢达

最佳答案

我们公司采用类似的流程:

1. 我们在发行部门工作
2. 在 BitBucket 中创建 pull 请求
3. 高级开发人员审查和批准(或不批准)
4. 如果不存在 merge 冲突，则 merge
5. 如果存在 merge 冲突，开发人员必须解决它们，他们将 merge 它

请注意，我在这里说的是 merge ，而不是 rebase 。对于粗心的人来说， rebase 充满了危险。 rebase 时，您将放弃现有的提交并创建相似但不同的新提交。如果你推送到 BitBucket 而其他人将它们 pull 下来并基于它们进行工作，然后你用 git rebase 重写这些提交并再次推送它们，你的同事将不得不重新 merge 他们的工作和东西当您尝试将他们的工作 pull 回您的工作时，他们会变得一团糟。沿着这些思路可能会发生一些事情，当你的分支(或他们的)不在时，一位同事重新调整了他的工作并粉碎了你的提交。可以通过明智地使用 git log 来确定哪个提交是哪个提交来解决这个问题。

展望 future ，我建议 merge 而不是 rebase 。正如我上面提到的，如果 Pull Request 上没有 merge 冲突，则什么都不做。如果有，这里是解决它们的过程:

git fetch origin <Team's Main Branch>
git merge FETCH_HEAD <your branch>
-- make and stage fixes
git commit
git push

https://stackoverflow.com/questions/39075781/