私が唯一の開発者である場合、自分のリポジトリでプルリクエストを使用する目的はありますか？

だから私はGitHubで私の本当のプロジェクトを始めました。物事はかなり順調に進んでおり、アイデアは当初思っていたよりもずっと速く流れていました。物事を整理するために、いくつかのブランチをセットアップして、異なる機能を個別に開発できるようにします。

私はGitHubのに私の枝を押すと今、私は私は2つのボタンがあり、そのセクションがありますPull Requestし、Compare私は最近にプッシュブランチの名前を持ちます。Compareボタンの目的は理解していますが、自分のリポジトリでプルリクエストを作成する理由がわかりません。

誰かが私がそうする理由を説明できますか？自分が唯一の開発者である場合、自分のリポジトリでプルリクエストを行うことは有用ですか？

多くの（おそらくほとんどの）個人開発者が自分で作業している場合、プルリクエストを作成する価値はおそらくないでしょう。ただし、それを行うには、少なくとも1つの潜在的な理由が考えられます。

プルリクエストを使用すると、プロジェクトの履歴をより簡単に追跡できます。プルリクエストには、コミットメッセージと変更ログで参照できる問題IDがあります。これにより、機能を保持することなく、特定の変更のマージポイントとマージされたコミットのセットを簡単に見つけることができます。無期限に分岐します。

たとえば、Pioneer（恥知らずのプラグ）では、プルリクエストをマージするときに、変更の1行の説明とプルリクエストIDへの参照を含むアイテムをchangelogに追加します。もちろん、パイオニアには複数の開発者がいますが、同じメカニズムは、自分で作業する開発者にとっても有用です。

これは、（コミットの前に機能ブランチをリベースして、マージを常に早送りとして実行できるように）線形コミット履歴に固執することに決めた場合、およびマスターにマージする前にコミットします。その場合、個々のコミットメッセージを変更ログとして使用できるためです。

プルリクエストが作成されるので、誰かが作業をレビューし、コメント、提案を行い、編集を行うかリクエストしてから、コードをマスターにマージできます。

あなたの場合、誰かがあなたです。

唯一の開発者として、自分の作業をレビューし、リファクタリングし、準備ができたらマスターにマージする必要があります。

私がよく使うアプローチの1つは、「別の帽子をかぶる」「他のペルソナを試す」ことです。したがって、しばらく座って、次の状況に身を置いてください。ジュニア開発者; 過去に尊敬していた同僚など。彼らの目を通してそれを試してみて、部族や領域の知識をできるだけ避けて、より明白な、より良い名前で書かれた変更をより簡単にするために何ができるかを考えてみてください。

そのため、既に述べたように、マスターの準備が整っていない機能と変更を分離する場合は、ブランチで作業する必要があります。これらはすべてブランチで実行できます（PRタスクを実行する場合、プルリクエストで管理する必要はありませんが、便利な構造を提供します）。

また、私は時々私の変更が機能していないことがわかりますが、マスターからそれをバックアウトしようとする恐怖ではなく、おそらく他のマスターの変更と混合して、ブランチでそれをすべて行うことができます/うまくいかない場合は削除します。これは大きな利点です。

だから、必要がある支店で作業していない、あなたが全体のブランチをマージすることを決定するまで、マスターに直接コミット。

これらは従うべきガイドラインであり、ルールではありません。私は意図的にそれらを時々壊します。たとえば、昨日、マスターにタイプミスを修正しました。

ローカルブランチだけでなくリモートブランチもあるようです。そのワークフローのオーバーヘッドが多すぎる場合は、ローカルブランチをプッシュせずに、さまざまな機能をいつでも使用できます。

それは基本的にあなたのために働くことをすることになります。ブランチでの作業はgitにとって大きな利点です。githubはそれを本当に簡単にしますが、単独の開発者としてプルリクエストモデルを使用する必要はあまりなく、マスターに直接コミットすることはうまくいくはずです。プロジェクトが最終的に信じられないほど成功し、数十または数百人の開発者がプロ​​ジェクトに取り組んでいるとき、あなたは彼らのフォークからプルリクエストを取得することがプロジェクトを追跡する素晴らしい方法であることがわかります。

プルリクエストは、通常、コードレビューまたはプロジェクトの独自のフォークを持つユーザーからの投稿のいずれかに使用されます。プロジェクトの1人の開発者にとっては、私にはあまり目的がありません。

私がそれをする理由は、すべての自動化されたチェックがパスすることを確認する便利な方法だからです（コンパイルされ、正しいフォーマットを持ち、単体テストがパスする...）。

コミットごとに必ずしもすべてのチェックに合格する必要はありませんが、メインブランチのヘッドが常にチェックに合格するようにします。プルリクエストは簡単な方法だと思います（おそらく唯一の方法ではありません）。

より一般的には、フックを接続して変更を完了する方法です。テストは一例です。@Johnは、別の例としてリリースノートの作成に言及しました。

プルリクエストとgitプッシュは、最終的に個々の履歴または共有履歴のいずれかになります。メインリポジトリは、すべての変更のソースです。他のユーザーがローカルの変更を取得し、潜在的にローカルの変更を行う場合、プッシュリクエストにより、変更から派生したツリーとしてユーザーの問題が発生する可能性があります。

プルリクエストモデル（カスタムブランチまたは個人リポジトリから）は、コードを使用およびコードから派生したすべての人に一貫した履歴を提供する方法として機能します。

githubにコードを配置する理由の一部は、コードをフォークおよびプル要求に使用できるようにするためです。いつそれが起こるかわからないので、共同開発者の履歴の一貫性を保つことは大きなプラスになります。