プルリクエストを開始するか、マスターでローカルマージコミットを実行する方が良いですか？
私はかなり長い間GitHubを使用しており、通常は機能ブランチをプッシュしてから、自分でマージしたプルリクエストを開始していました。ブランチをマージした場所を追跡するのに役立つことがわかりました。
しかし最近、Gitがどのように機能するかについてますます読むようになり、ブランチをマージしたときを参照するためにマージコミットを使用できることがわかりました。
それで、機能ブランチをマスターにマージするときに何をすべきですか：
マスターでマージコミットを実行してから、上流にプッシュします[〜＃〜]または[〜＃〜]ローカルブランチをプッシュしますプルリクエストを開始しますか？
私は 2人のチームのプルリクエストの概要-自分のリクエストをマージしますか？ と プロジェクトの2人のワークフローとは と 開く必要があります公式リポジトリまたは私のフォークのブランチからのプルリクエスト？ しかし、それらのどれも私が探しているものに答えていないようです。
git-mergeメカニズム：
マスターでgit merge featureを使用すると、ブランチfeatureがmasterにマージされ、merge-commit（ブランチを早送りできない場合）が生成されますgitの履歴。 merge-commitを強制的に作成するには、mergeで--no-ffオプションを使用します。
マージプルリクエストメカニズム：
GitHubでプルリクエストを開始すると、GitHub Issueが作成され、マージする前にPRでコミットを話したり、議論したりできます。 GitHubでPRがマージされると、git merge featureとまったく同じことを行います。
どうすればいいですか？
したがって、歴史に関する限り、2つの間に違いはありません。
そして貢献に関しては、貢献者は2つの状況で何も異なる必要はありません。それらは同じです（Nice little chatを除いて）。
ベストプラクティス：
また、ベストプラクティスを見つけることができませんでしたが、リポジトリに1人しかいない場合、PRはあまり役に立たないとロジックは言っています。
@lxrecと@amonは、この結論に到達するのに役立ちました。
Ashharが言ったように、技術的にも歴史的にも違いはありません。小さなチームのプロジェクトの場合、私はPRを作成する追加のステップではなく、直接マージすることを好みます。ただし、機能にレビュー/フィードバックが必要な場合、またはWIPで複数の人が作業している場合は、PRを開いてタスクのリストをPRの説明に追加する傾向があります。
ご了承ください git mergeは、マスターに変更がない場合、早送りを使用する可能性があるため、git merge --no-ff。しない傾向があります。
要約すると、議論が必要な場合にのみPRを使用します。それ以外の場合は、直接マージします。