上流のレポに同時に貢献し、それから分岐するための適切なエチケットと推奨されるGitHubワークフローとは何ですか？

Question

GitHubとVCSは初めてです。私は長年さまざまな言語でプログラミングしてきましたが、カスタムプロジェクトでは常に単独で作業してきました（公開リリースはありません）。最近取り組んでいるプロジェクトで、GitHubからダウンロードしたjQuery UIウィジェットを使い始めました。リポジトリは、元の作者によってもはや維持されていません。別のフォークには、元のプルリクエストの一部が組み込まれています。これは私がフォークしたものです。

私はいくつかのバグを見つけ、それらの修正を思いつきました。これらの修正を提供したいのですが、私自身が使用するために、既存の機能の一部を壊すことになる他の変更もたくさんあります。さらに、別のフォークのアイデアを取り入れたいと思います。

私はまだGITとGitHubを学んでおり、すべてに取り組む最善の方法を見つけ出そうとしています。ワークフロー、マージ、プルリクエスト、チェリーピッキング、リベース、ブランチなど、さまざまな概念/タスクについてたくさん読んでいます（ここでは、SO、GitHubヘルプページ、Pro Git）。私の灰白質は水泳で、私はdoingを開始する必要があるので、読んだ内容をよりよく理解できます。

主な問題：

私は（どこかで）ブランチで一度に1つのプルリクエストしか持てないことを読んだと思います。それでは、バグごとに個別のブランチを用意し、バグごとに個別のプルリクエストを行う必要があるということですか。
空白の問題を解決したいのですが、別のコミットでこれを行うのが最善であることを読んだことを覚えているようです。これをマスターまたは別のブランチで実行する必要がありますか？私は何かのためにプルリクエストをしたくないトリビアルですが、ブランチの前に空白を変更すると、バグ修正のプルリクエストに影響しますか？一部のフォークは空白のクリーンアップを行い、その結果、diffは実質的に役に立たなくなりました。
すでにバグを修正しているにもかかわらず、バグを文書化する方法として、フォークに対して問題を作成することを考えていました。それは良い考えですか？問題、コミット、マスターへのマージをどのようにリンクするのですか？アップストリームでプルリクエストを行うと、自分の問題もアップストリームで表示されますか、それともそのドキュメントリンクは失われますか？上流のリポジトリに対して問題を開くことができません（問題タブはありません）。
私が使用したい彼のアイデアについて他のフォーク作者に信用を与えるための最良の方法は何ですか？特に彼の変更がアップストリームの古いバージョンに対して適用され、他の変更と互換性がないため、私は彼のコードを正確に使用できません。しかし、私はそのアイデアを使いたいし、クレジットが支払われるべきところにクレジットを与えたいです。私のコミットメッセージで彼のリポジトリ（またはプロファイルまたは特定のコミット）にリンクする必要がありますか？
メインファイルの上部にあるreadmeファイルとDocBlockの変更に関するエチケットは何ですか？変更を加えたり、名前を追加したり、リポジトリとデモへのリンクを追加したり、元のデモへのリンクを削除したりしてもかまいませんか（私のフォークは元のフォークと互換性がなくなるため）。もちろん、元の作者名とライセンス情報は残しておきます。記録のために、それはMITライセンスの下でライセンスされています。

VCSを使ったことがないソロ開発者として、私はrewrite historyに慣れています。私は完璧主義者で、きちんと整頓されていることが好きです。記録された歴史のアイデアは私を少し緊張させています、そして私は最初にそれを正しく行うをしたいです。再生/学習するための新しいリポジトリを作成しましたが、jQuery UIウィジェットの修正に取り掛かり、プロジェクトを続行できるようにしたいと思っています。

Marco · Accepted Answer

正しい例：プルリクエストはリポジトリのブランチにリンクされています。ブランチを変更すると、プルリクエストとして送信する内容も変更されます。

そのため、はい、バグ修正ごとにブランチ（およびプルリクエスト）を作成する必要があります。 1つから始めて、残りの作業に進む前に、メンテナがその1つにどのように反応するかを確認するのが賢明かもしれません。オープンソースは本質的に社会的なプロセスです。
Do空白の変更をプルリクエストします！メンテナーになることがある人と言えば、私はこの種のプルリクエストが大好きです。私はそれらを承認するかしないかを決め、処理にほとんど時間をかけません。

あなたが遭遇するかもしれないことは、メンテナがあなたの空白の変更に同意しないことです！だから、注意してください。
うーん..ここで何を達成しようとしているのか明確ではありません。ドキュメントが多すぎるように聞こえますが、これは良いアイデアではありません。これを行う理由を明確にできるでしょうか。
コミットメッセージ（またはコード内のコメント）で彼のリポジトリにリンクすることは、クレジットを与えるための優れた方法です。ただし、注意してください。彼のコードに対してideasおよびnotを感謝していることを明示してください。コードをコピーした場合は、彼がコードに使用しているライセンスが明確でない限り、私は彼にメールで連絡します。ライセンスが明確である（そして、それがコミットを送信するリポジトリからの異なるライセンスである）場合、プルリクエストに別のライセンスを追加し、プルにそれを記載する必要がありますリクエストメッセージ。
これは本当に良い質問で、あなたが話す相手によって異なります。私の意見では、コミットやコードに名前を付けてはいけません。主な理由は、「コードの所有権と責任」を暗示することです。「それはあなたのもの」であるため、他の人がコードを変更するのを妨げる可能性があります。しかし、今、私たちはオープンソースの性質について大きな議論を始めているので、ここで立ち止まって、プロジェクトのメンテナに尋ねるか、単にそれを実行して、彼の反応を見てみましょう。
GITを使用して（まだ公開されていないローカルの）履歴を書き換えることができます。 git rebaseコマンドを学ぶ-これが、私がgitを愛する主な理由の1つです。書き換えられたコミット/履歴を共有リポジトリ（たとえばgithub）に（強制的に）プッシュするのは本当に悪い考えです。これにより、他の開発者が持っているリポジトリが台無しになります-（書き換えられた履歴）変更をプルする際に、困難な作業を行わなければなりません。

[＃6：@toxalotに感謝！]