bitbucket

Question

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

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

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

谢谢阿尼卢达

Answer 1

我们公司使用类似的流程：

我们在问题分支工作
在 BitBucket 中创建拉取请求
高级开发人员审核并批准（或不批准）
如果不存在合并冲突，则合并
如果存在合并冲突，开发人员必须解决它们，他们将合并它

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

展望未来，我建议合并而不是变基。正如我上面提到的，如果 Pull Request 上没有合并冲突，则什么都不做。如果有，这里是解决它们的过程：

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

bitbucket - 看不到合并分支的提交

bitbucket - can not see commit of merged branch

git