プルリクエストを開始するか、マスターでローカルマージコミットを実行する方が良いですか？

私はGitHubをかなり長い間使用しており、通常は機能ブランチをプッシュしてから、自分でマージしたプルリクエストを開始していました。ブランチをマージした場所を追跡するのに役立つことがわかりました。

しかし最近、Gitの仕組みについてますます読んでおり、マージコミットを使用してブランチをマージするときに参照できることに気付きました。

マスターに機能ブランチをマージするときだから、私は何をすべき：
実行し、マージコミットマスターにして、それが上流押しORローカルブランチを押して、プルリクエストを開始しますか？

2人のチームのプルリクエストの紹介を読みました-自分のリクエストをマージしますか？そしていただきましたプロジェクトの2人との作業の流れと公式レポや私のフォーク上の枝から万一Iオープンプル要求？しかし、彼らは誰も私が探しているものに答えていないようです。

gitのマージメカニズム：
使用git merge featureマスターはブランチをマージ上ながらfeatureにmasterして生成しmerge-commit（分岐が早送りできない場合）Gitの歴史の中で。強制的merge-commitに作成するには、で--no-ffオプションを使用しますmerge。

プルリクエストのマージメカニズム：
GitHubでプルリクエストを開始するGitHub Issueと、マージする前にPRのコミットについて話し合い、議論できる場所が作成されます。PRがGitHubにマージされると、PRとまったく同じことを行いgit merge featureます。

私は何をすべきか？
したがって、歴史に関する限り、2つの間に違いはありません。
そして、貢献に関する限り、あなたの貢献者は、2つの状況で異なることをする必要はありません。それらは同じです（マイナスの素敵な小さなチャット）。

ベストプラクティス：ベストプラクティス
を見つけることはできませんでしたが、リポジトリに1人しかいない場合、PRはあまり役に立たないとロジックは言っています。

@lxrecと@amonは、私がこの結論に達するのを助けました。

以下のようAshharは言った、技術的にも歴史ワイズ違いはありません。小さなチームのプロジェクトでは、PRを作成する追加のステップではなく、直接マージすることを好みます。ただし、機能のレビュー/フィードバックが必要な場合、またはWIPであり、複数の人が作業する場合、PRを開き、PRの説明にタスクのリストを追加する傾向があります。

注git mergeマスターに変更がない場合に使用する場合がありますので、早送り使用することがありますgit merge --no-ff。しない傾向があります。

要約すると、ディスカッションが必要な場合にのみPRを使用してください。それ以外の場合は、直接マージします。