GitHubでプロジェクトを編集するためのPRをどのように作成しますか?
このトピックについては多くのチュートリアルが存在しますが、貢献する必要があると想定することにより、物事が過度に複雑になりますコードプロジェクトに。だから、すべてがありますギットその前にセットアップします。
ファイルを編集する必要がある場合はどうなりますか?おそらくプロジェクトREADMEでタイプミスを修正しますか?
コーディング方法やGitを使用してそれを行う方法を知る必要はありません。しかし、プルリクエストを開始すると、さらに多くのことを実行して、他の人とプロジェクトで共同作業を行うことができます。そして多分これはあなたに後でコードを提供するようにあなたを押すでしょう。
私はあなたがすでに(無料)を持っていると思いますGitHubアカウント。そうでない場合は、github.comそして1つを取得します。
プロセスをお見せしましょう。
このページに行きましたhttps://web.dev/prefers-color-scheme/そして私は可能性のあるタイプミスを見つけました。この行の最後にドットがありません。
私は文法ナチではありません、これは例を見つけるためだけです😄
私はサイトがGitHubでホストされていることを知っています、そしてその正確な記事はここでホストされています:https://github.com/GoogleChrome/web.dev/tree/master/src/site/content/en/blog/prefers-color-scheme
index.mdファイルを開きますhttps://github.com/GoogleChrome/web.dev/blob/master/src/site/content/en/blog/prefers-color-scheme/index.mdGitHubで直接、ファイルツールバーの鉛筆アイコンを押します。カーソルを合わせると、「このプロジェクトをフォークしてファイルを編集してください」と表示されます。
これにより、次の情報を含むエディタービューが表示されます。
書き込みアクセス権がないプロジェクトのファイルを編集しています。このファイルに変更を送信すると、フォークflaviocopes / web.devの新しいブランチに書き込まれるため、プルリクエストを送信できます。
そのドットを追加して、下部のフォームで行った変更について説明します。
「ファイル変更の提案」ボタンを押すと、比較ビューが表示されました。
そこで、行った変更を確認して、すべてが正常であることを確認し、最後に[プルリクエストの作成]ボタンをクリックします。現在、変更が加えられていますあなたのフォーク鉛筆アイコンをクリックするとGitHubによって自動的に作成されたプロジェクトの
このビューの上部に、PRを送信しようとしていることがわかります。GoogleChrome/web.dev
私のフォームからのプロジェクトflaviocopes/web.dev
、私の支店からpatch-2
彼らにmaster
ブランチ。
「プルリクエストの作成」ボタンを押すと、プルリクエストの詳細な説明を書くことができる別のフォームが表示されます。
プルリクエストにはさまざまな変更を含めることができるため、理論的には同じPRで多くのファイルを編集できるため、要約を追加できます。
このリポジトリには、チームが管理できるように、PRテキストのテンプレートがあります。私たちのPRは非常に単純なので、テンプレートを削除して、以前のコミットメッセージからコンテンツを貼り付けるだけです。
右側のヒントに気づきましたか?彼らは、プロジェクトにCONTRIBUTING.mdファイルがあり、貢献する方法とガイドラインを説明していると言っています。かなりクール。
PRを完了するには、CLA(貢献者ライセンス契約)に署名する必要があるようです。私は過去にすでにGoogleCLAに署名しているので、この手順は明らかですが、修正する必要があるかもしれません。ほとんどのプロジェクトは実際にはそれを必要としません。
「プルリクエストの作成」をクリックすると、PRが送信されます。
これで、プロジェクトのメンテナが介入して受け入れることができます。マージされたことを通知する電子メール、または他の人からのコメントを待つ必要があります。
[…数時間経ちました…]
メールが返ってきましたが、そのドットが実際に正しい場所にあったため、PRは拒否されました。 (私はそれを知りませんでした)。
しかし、とにかくここに私が付け加えたかったことがあります:あなたが提出するPRが受け入れられなくても怒ったり動揺したりしないでください。プロジェクトのメンテナは数ヶ月または数年にわたってプロジェクトに取り組み、彼らはあなたよりもプロジェクトにとって何が良いかをよく知っています。
さらに、特にコードの場合、ビューは非常に異なる可能性があり、優れていると思うPRは歓迎されない可能性があります。
また、実質的なPRに取り組む前に、プロジェクトが実際に必要としているものであるかどうかを確認することをお勧めします。
しかし、これはそれ自体がトピックです。
その他のgitチュートリアル:
- Gitチートシート
- 複数のブランチでの作業を管理するためのGitワークフロー
- Gitサブリポジトリを処理する簡単な方法
- 優れたGitチュートリアルの不完全なリスト
- 開発者によるGitHubの紹介
- 完全なGitガイド
- gitbisectを使用してバグを発見する方法
- GitHubで最初のプルリクエストを行う方法
- 別のブランチからGitブランチを更新する方法
- パスワード/ APIキーをGitHubに投稿しました
- Gitを押しつぶすコミット
- Gitリモートを削除する方法