githubのメンテナーはプルリクエストで著者を書き換えるべきですか？

私は専門職のプログラマーではありませんが、いくつかのコーディングを行い、githubを使用しています。私は驚くべき状況だと思うことに出くわしました。私はgitに精通しています。

私に影響を与えている（小さな）バグを見つけたプロジェクトがあります。午後はそれを見つけて修正しました。リポジトリをフォークし、変更をコミットし、プルリクエストを発行しました。「開発ブランチにマージされた」として閉じられているのを見て、すべてがうまくいったと思いました。

今日、ブランチを削除する準備をしてレポジトリを参照していましたが、メンテナのレポジトリにコミットがマージされた場所がまったく見つかりません。しばらくして、コミットとして追加されたことに気付きましたが、作成者は私ではありません。

私ができる限り、それを行う唯一の方法は、元の著者を削除するためにリベース、修正、またはその他の履歴書き換えを具体的に使用することです。

これは私には非常に間違っているようです。せいぜい紛らわしいです。最悪の場合、このレポの作成者は全員のコミットを信用しているため、元の貢献者の履歴は失われます。繰り返しますが、これは小さなバグです。プロの履歴書には使用していません。不正直に思えます。

これは正常ですか？私はそれについて何か言うべきですか？

編集：一般的な感じは私が尋ねに行くべきだと思われるので、私は今朝ちょうどそれをします。

以下のリクエストに従って。私はチェックし、コードが存在し、私が書いたとおりに正確に適用されました（コメントを含む）。コミッターと著者の両方が変更されたことを確認しました。私の変更と同時に追加された変更も1つありました。これは1行で、パッチとそれ以前のその他のコードに影響します。IEの1行の追加は、修正していたバグとは関係ありません。

更新 答えは、作成者が開発ブランチを維持しており、マスターブランチからそこにマージしたくないということでした。彼はマージを回避するために私のコミットを再作成しました。元のブランチb / c gitは、必要に応じてコミットをチェリーピック、リベース、およびマージするのに強力です。

これはgithubでは一般的ですか？
どのブランチにパッチを適用するかを尋ねるためにプロジェクトのメンテナーに連絡する必要がありますか？

いいえ、回避可能であれば、そうすべきではありません。私の経験ではあまりにも頻繁に起こるのは問題です。ただし、クレジットを盗もうとする人よりも、gitを正しく使用する方法を知らないことに関係があると思います。

• 変更をメインブランチに適用する前に変更したい場合、変更用のブランチを簡単に作成できます。その後、自分のコミットを自分のコミットの後に追加し、ブランチをマージできます。
• プルリクエストがメインブランチの最新バージョンに基づいていない場合、を発行できgit rebase masterます。競合がある場合は、競合を自分で修正する（作成者を変更せずに）か、修正する機会を与えることができます。

Githubは、この種の偶発的なクレジットスチールを探し、適切な場合はベストプラクティスについてメンテナーを教育することができ、またそうすべきだと思います。

ここで重要な詳細を省略しました。

• バグを「修正」する方法が、好みのメンテナではない場合、またはバグが発生するという点で間違っている場合、メンテナはコミットする前に作業を編集する必要があったかもしれません。その場合、著者を変更することは理解できます。

• 他の人が言及したように、著者はコミッターとは全く異なり ます。すでにご存じかもしれませんが、作成者は実際にコミットを作成した人であり、コミッターはそれを適用する人です。

コミットをよく見て、調査結果で質問を更新する必要があります。

答えは、作成者が開発ブランチを維持しており、マスターブランチから開発ブランチにマージしたくないということでした。彼はマージを避けるために私のコミットを再作成しました。

更新された質問に回答するには：

通常、すべてのプロジェクトは異なり、それぞれに好みのワークフローがあると言うことを超えて、githubで典型的なことを言うことは困難です。一般に、プルリクエストを送信する前の最善のアプローチは、ワークフローとは何かを尋ねるか、以前のクローズされたプルリクエストに基づいて判断できるかどうかを確認することです。

私の個人的な経験は、あなたが尋ねない場合、一般的に彼らはせいぜいコメントなしでプルリクエストを閉じる（最悪の場合）、またはベストケースはあなたがプルリクエストを更新するよう求めている手順を説明するコメントを残すことです。あなたの場合のメンテナーがそれを処理した方法は奇妙に思えますが、それは彼らにとって最も抵抗の少ない道だったかもしれません。私はそれが意図的に信用を盗むことを意図していたとは思わない。

将来の混乱や信用不足を避けるために、プルリクエストをどのように受け取りたいか、どのブランチに対して行うかを説明するドキュメントを追加するようメンテナーに依頼することをお勧めします。もっと多くのプロジェクトがこのドキュメントを提供してくれることを望んでいます。それは、人々がプロジェクトに参加することをより多く望むようになると思うからです。