github维护者是否应该在pull请求中重写作者的？

我不是专业的程序员，但是我做了一些编码，并使用了github。我遇到了令人惊讶的情况。我对git非常熟悉。

我有一个项目发现一个（小）错误影响了我。我花了一个下午找到并修复它。我分叉了存储库，提交了更改，并发出了请求请求。看到它关闭为“合并到开发部门”后，我发现一切都很好。

我今天正在浏览存储库，准备删除分支，但根本找不到提交合并到维护者存储库中的位置。一段时间后，我意识到它已被添加为提交，但作者不再是我。

据我所知，唯一的方法是专门使用重新基准，修改或其他历史记录重写来删除原始作者。

我觉得这很不对劲。充其量是令人困惑的，最糟糕的是，此回购协议的作者会为每个人的贡献表示赞赏，然后失去了原始贡献者的历史。再次，这是一个小错误，我不会在专业简历中使用它，这似乎是不诚实的。

这正常吗？我应该说些什么吗？

编辑：总体感觉似乎是我应该去问问，所以今天早上我就去做。

按照下面的要求。我检查了一下，发现我的代码存在，并在编写它时（包括注释）被完全应用了。我确认提交者和作者均已更改。我的更改同时也添加了另一项更改。这是一行，可能会影响补丁程序以及之前的其他代码。IE浏览器的单行添加与我正在修复的错误无关。

更新 似乎答案是作者维护了一个开发分支，并且不想将其主分支合并到该分支中。他重新撰写了我的承诺以避免合并。我并不关心原始分支b / c git是否足够强大，可以根据需要进行选择，重新设置基础和合并提交。

这在github上是典型的吗？
我是否应该联系项目的维护者以询问向哪个分支应用补丁？

不，如果可以避免，他们不应该这样做。根据我的经验，这是一个经常发生的问题。但是我相信，与其说是想窃取信用，不如说是对如何正确使用git的无知。

• 如果他们想在将更改应用到其主分支之前对其进行修改，则可以轻松地为您的更改创建一个分支。然后，他们可以在自己的提交之后添加自己的提交，然后合并分支。
• 如果您的拉取请求不是基于其主分支的最新版本，则他们可以发出git rebase master。如果存在冲突，他们可以选择自己解决冲突（无需更改作者），或者给您解决的机会。

我认为Github可以并且应该寻找这种偶然的信用盗用行为，并在适当时向维护者提供最佳实践方面的教育。

您在这里省略了一些关键细节。

• 如果您“修复”该错误的方式不是维护者所喜欢的，或者甚至是错误的，因为它引入了自己的错误，那么维护者可能不得不在提交之前编辑您的工作。在这种情况下，更改作者是可以理解的。

• 正如其他人所提到的作者是来自完全不同的 提交者。您可能已经知道作者是实际创建提交的人，而提交者将是应用提交的人。

您应该仔细查看提交并使用您的发现更新您的问题。

似乎答案是作者维护了一个开发分支，并且不想将其主分支合并到该分支中。他重新撰写了我的承诺以避免合并。

要回答您的更新问题：

除了说通常每个项目都是不同的并且每个项目都有自己的首选工作流之外，很难说github上的典型情况。通常，发送拉取请求之前，最好的方法是询问其工作流程是什么，或尝试根据先前已关闭的拉取请求判断是否可以区分。

我个人的经验是，如果您不提出要求，通常他们最多会在不加评论的情况下关闭拉取请求（更糟的情况），或者最好的情况是他们留下评论来说明要求您更新拉取请求的过程。我要说的是，在您的案例中，维护者处理它的方式似乎有些奇怪，但是这可能只是对他们的抵抗最小的途径。我怀疑这是故意窃取信用。

我建议您请维护者添加文档，说明他们希望如何接收拉取请求以及针对哪个分支机构以避免将来出现混乱和信用欠佳的情况。我希望有更多项目提供此文档，因为我认为这会使人们更倾向于参与该项目。