Git快进式合并：有机会找到责任人吗？

Question

假设存在一个名为'my-feature'的特性分支。在开发过程中，有人将其从'my-feature'合并到了'master'分支。由于这是一个快进式合并，因此没有进行提交。我所做的一些更改还没有准备好用于'master'分支，当它被推送到'master'分支时，这些更改破坏了很多测试。然而，由于这些更改显然是我做的，责任被归咎于我，而不是执行快进合并的那个人（无论他是谁）。

是否有可能找出是谁将'my-feature'合并到'master'分支，即使这是快进式合并？如何防止类似情况在未来发生？

git reflog 显然只显示本地操作历史。我们使用的是GitLab服务器，但我还没有找到查看GitLab存储库的reflog的方法。有什么建议吗？

- digory doo

---

这是一个很好的问题/问题，我不知道答案。然而，这可能是许多提供者（如GitHub和Bitbucket）强制每个合并请求通过他们管理的审查流程的原因之一。如果这发生在GitHub或Bitbucket上，罪犯将立即被揭露。 - Tim Biegeleisen

GitLab 也有这个功能，但我怀疑团队不会同意每次都要通过合并请求。 - digory doo

GIT：哥德尔不完备性追踪器。 - Kaz

我能想到的唯一方法是检查每个人本地仓库的副本，查看reflogs等来发现是谁做的。但是，如果这个人知道他们在做什么，那么可能不会留下任何证据。至于如何防止这种情况发生，就是在你的功能分支准备好之前不要将其推送到中央仓库。如果你将它推送到中央仓库的原因是为了备份，请使用仓库的第二个个人副本，而不是中央副本... - twalberg

我同意@Tim的观点，并强烈建议阻止直接推送到主分支。你知道吗，你团队中的任何开发人员现在都可以立即将git push -f应用于你的历史记录，从而使其彻底消失？话虽如此，我怀疑是否存在某些ssh访问日志，至少你可以发现谁在什么时候做了什么。 - rubenvb

GitLab有一个更新钩子，可以防止任何人对受保护分支进行强制推送。我们的主分支是受保护的；但是开发人员仍然可以推送到主分支，因为我们都拥有GitLab主权限。 - digory doo

Answer 1

我唯一看到的机会就是在gitlab-shell.log中寻找一些线索。 reflog方法很可能行不通，因为对于裸库，默认情况下reflog是被禁用的。您可以按照这里的说明打开它。

---

编辑: 它不能用于快进合并，因为快进合并不会更改提交对象。

你应该尝试使用git log --pretty=full。

它将显示提交者(提交的人-不是你)以及作者(编写更改的人-你)。

- AnimiVulpis

---

这肯定是不对的。每个日志条目的作者和提交者都是一样的。显然，只有在重新应用补丁时它们才会有所不同，而在正常合并和快进合并中则从未有过差异。 - digory doo

@digorydoo：对的，这里的问题是因为这是一个快进（实际上并不是合并：它不能是合并，因为既没有进行合并工作，也没有创建合并提交），所以操作中没有用户名称。将附加用户名称的位置是日志文件：如果服务器上有引用日志，则会更新引用日志，或者是ssh或http服务器日志文件。 - torek

我使用ssh连接到服务器，但是git reflog命令没有列出任何内容。显然，git reflog命令不能用于裸库。 - digory doo

我在本地尝试了一下，提交者和作者不同。这就是为什么我认为它应该可以工作的原因。编辑：重新尝试了一下，现在无法工作。似乎第一次做了些不同的事情。 - AnimiVulpis