私が唯一の開発者である場合、自分のリポジトリでプルリクエストを使用する目的はありますか？
それで、私は GitHub で私の実際のプロジェクトを開始しました。物事を整理しておくために、いくつかのブランチをセットアップして、さまざまな機能を個別に開発できるようにしました。
ブランチをGitHubにプッシュすると、そのセクションに2つのボタンがあります。Pull RequestとCompareは、最近プッシュしたブランチの名前です。 Compareボタンの目的を理解しましたが、自分のリポジトリでプルリクエストを作成する理由がわかりません。
なぜ私がそうするのか、誰かが私に説明してもらえますか？私が唯一の開発者である場合、自分のリポジトリでプルリクエストを行うことは役に立ちますか？
自分で作業する多くの（おそらくほとんどの）個人開発者にとって、プルリクエストを作成することはおそらく価値がありません。ただし、それを行うには、少なくとも1つの理由が考えられます。
プルリクエストを使用すると、プロジェクトの履歴をより簡単に追跡できます。プルリクエストには、コミットメッセージおよび変更ログで参照できる課題IDがあり、機能を保持する必要なく、簡単に戻って特定の変更のマージポイントとマージされたコミットのセットを見つけることができます。無期限に分岐します。
たとえば、 Pioneer （恥知らずなプラグイン）では、プルリクエストをマージするときに、変更の1行の説明と変更を含む changelog にアイテムを追加します。プルリクエストIDへの参照。もちろん、Pioneerには複数の開発者がいますが、同じメカニズムは、開発者が自分で作業する場合にも役立ちます。
これは、（コミットの前に機能ブランチをリベースして、マージを常に早送りとして実行できるようにする）線形コミット履歴に固執することを決定した場合、および、マスターにマージする前にコミットします。その場合、個々のコミットメッセージ自体を変更ログとして使用できるためです。
プルリクエストが作成されるので、誰かが作業をレビューし、コメント、提案を行い、編集を行ったりリクエストしたりしてから、コードをマージしてマスターできます。
あなたの場合、誰かがあなたです。
唯一の開発者として、自分の作業をレビューし、リファクタリングし、準備ができたらマスターにマージする必要があります。
私がよく使うアプローチの1つは、「別の帽子をかぶる」、「他の人格を試す」ことです。しばらく座って、次のような状況に身を置きます。グループの初心者。ジュニア開発者;過去に尊敬していた同僚など。目を通してそれを試してみて、変更をより明確にし、部族やドメインの知識をできるだけ避け、さらに優れた名前でより適切に記述できるようにするために何ができるかを考えてみてください。 。
したがって、先に示したように、マスターの準備が整っていない機能と変更を分離する場合は、ブランチで作業する必要があります。これらはすべてブランチで実行できます（とにかくPRタスクを実行する場合は、プルリクエストで管理する必要はありませんが、便利な構造が提供される場合があります）。
また、私の変更が機能していないことが時々ありますが、マスターからバックアウトしようとする恐怖ではなく、おそらく他のマスターの変更と混ざり合って、私はそれを無視できるブランチですべて行うことができます/うまくいかない場合は削除してください。これは大きなメリットです。
したがって、ブランチ全体をマージすることを決定するまで、ブランチで作業するすべきとnotを直接コミットします。
これらは従うべきガイドラインであり、ルールではありません。私は意図的にそれらを時々壊します。たとえば、昨日、入力ミスの修正をマスターにコミットしました。
ローカルブランチだけでなくリモートブランチもあるようです。そのワークフローのオーバーヘッドが多すぎる場合は、ローカルブランチを使用して、さまざまな機能をプッシュせずにいつでも作業できます。
それは基本的にあなたのために働くことをすることに帰着します。ブランチを操作することはgitにとって大きなメリットであり、githubはそれを本当に簡単にしますが、単独の開発者としては、プルリクエストモデルを使用する必要はあまりなく、マスターに直接コミットすることでうまく機能するはずです。プロジェクトが最終的に信じられないほど成功し、数十人から数百人の開発者がそれに取り組んでいるとき、フォークからプルリクエストを取得することは、プロジェクトを追跡するための優れた方法であることがわかります。
プルリクエストは通常、コードレビューまたはプロジェクトのフォークを持つユーザーからの寄稿のいずれかに使用されます-プロジェクトの1人の開発者にとって、目的は実際にはわかりません。
私がそれを行う理由は、すべての自動化されたチェックに合格することを確認するための便利な方法であることです（コンパイルされ、正しいフォーマットがあり、ユニットテストに合格します...）。
コミットごとにすべてのチェックにパスする必要はありませんが、メインブランチのヘッドに常にチェックをパスさせたいです。プルリクエストは簡単な方法だと思います（おそらく唯一の方法ではありません）。
より一般的には、フックを接続して変更を完了する方法です。テストは一例です。 @Johnは、別の例としてリリースノートの作成について言及しました。