アップストリームリポジトリへの貢献とアップストリームリポジトリからの分岐を同時に行うための適切なエチケットと推奨されるGitHubワークフローとは何ですか?


21

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

いくつかのバグを発見し、それらの修正を考え出しました。私はこれらの修正に貢献したいと思いますが、私たち自身の使用のために、既存の機能のいくつかを破壊する他の多くの変更もしたいと思います。さらに、別のフォークのアイデアを取り入れたいと思います。

私はまだGITとGitHubを学んでおり、あらゆることを行うための最善の方法を見つけようとしています。さまざまな概念/タスク(ワークフロー、マージ、プルリクエスト、チェリーピッキング、リベース、ブランチ)について多くの読書(ここでは、SO、GitHubヘルプページ、Pro Git)を行いました。私の灰白質は泳いでいるので、読み始めたことを理解するために、始めなければなりません。

主な問題:

  1. 私は(どこかに)一度にブランチ上でプルリクエストを1つしか持つことができないと読んだと思います。つまり、バグごとに個別のブランチを作成し、それぞれに個別のプルリクエストを実行する必要があるということですか?

  2. 空白の問題をクリーンアップしたいのですが、これを別のコミットで行うのが最善であると読んだことを覚えているようです。これをマスターまたは別のブランチで行う必要がありますか?些細なことに対してプルリクエストをしたくありませんが、ブランチする前に空白を変更すると、バグ修正のためのプルリクエストに影響しますか?一部のフォークは空白のクリーンアップを行い、事実上、diffをかなり役に立たなくしました。

  3. 私はすでにバグを修正しているにもかかわらず、バグを文書化する方法として、フォークに対して問題を作成することを考えていました。それは良い考えですか?問題、コミット、およびマスターへのマージをリンクするにはどうすればよいですか?アップストリームでプルリクエストを行うと、問題もアップストリームに表示されますか、それともドキュメントのリンクが失われますか?アップストリームリポジトリに対して問題を開くことができません([問題]タブはありません)。

  4. 私が使用したい他のフォーク作成者のアイデアを他のフォーク作成者に与える最良の方法は何ですか?特に彼の変更はアップストリームの古いバージョンに対して適用され、他の変更とは互換性がないため、私は彼のコードを正確に使用することはできません。しかし、私はこのアイデアを使いたいですし、クレジットが支払われるべきところでクレジットを与えたいです。コミットメッセージで彼のレポ(またはプロファイルまたは特定のコミット)にリンクするだけですか?

  5. メインファイルの上部にあるREADMEファイルとDocBlockの変更に関するエチケットは何ですか?変更を行い、名前を追加し、リポジトリとデモへのリンクを追加し、元のデモへのリンクを削除しても構いません(私のフォークは元のデモと互換性がないため)もちろん、元の著者名とライセンス情報は残しておきます。記録のために、それはMITライセンスの下でライセンスされています。

VCSを使用したことがないソロ開発者として、私はhistory書き換えることに慣れています。私は完璧主義者で、きちんと整理整頓することが好きです。歴史を記録するという考えは私を少し緊張させています。プレイ/学習するための新しいリポジトリを作成しましたが、jQuery UIウィジェットの修正を進めて、プロジェクトを進めることができるようになりたいと思っています。

回答:


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

    そのため、バグ修正ごとにブランチ(およびプルリクエスト)を作成する必要があります。1つから始めて、メンテナーがその1つにどのように反応するかを確認してから、残りを実行するのが賢明かもしれません。オープンソースは本質的に社会的なプロセスです。

  2. Doがあなたの空白の変更のためのプルリクエストを作ります!時々メンテナーになる人として、私はこれらのタイプのプルリクエストが大好きです。私はそれらを承認するかしないかのどちらかであり、処理するのに少し時間がかかります。

    あなたがまた遭遇するかもしれないことは、メンテナーがあなたの空白の変更に同意しないということです!だから、注意してください。

  3. うーん。ここで何を達成しようとしているのか明確ではありません。過剰な文書化のように聞こえますが、それほど良いアイデアではないようです。おそらく、これを行う理由を明確にできるでしょうか。

  4. コミットメッセージ(またはコード内のコメント)で彼のリポジトリにリンクすることは、信用を与えるための素晴らしい方法です。けれども注意してください-あなたが彼のために彼に感謝していることを明示的に作るアイデアない彼のコードのために。あなたがコードをコピーした場合、彼がコードに使用しているライセンスが非常に明確でない限り、私はそれについて彼に電子メールを送るでしょう。ライセンスは明らかである(そしてそれはだ場合は別のあなたがするコミットを提出しているリポジトリからライセンス)あなたは、あなたのpull要求で別のライセンスを追加しても、あなたのプル要求メッセージであることに言及。する必要があります

  5. これは本当に良い質問で、誰と話すかによって異なります。私の意見では、実行するコミットやコードに名前を追加しないでください。主な理由は、「コードの所有権と責任」を暗示しているためです。「それはあなたのもの」であるため、他の人がコードを変更できないようにするためです。しかし、今はオープンソースの性質について大規模な議論に入っているので、ここで立ち止まって言います-プロジェクトのメンテナーに尋ねるか、それをして、彼の反応を見てみましょう。

  6. GITで(まだ公開されていないローカルの)履歴を書き換えることができます!git rebaseコマンドを学ぶ-これが私がgitを愛する主な理由の1つです。書き換えられたコミット/履歴を共有リポジトリ(githubなど)に(強制的に)プッシュするのは、本当に悪い考えです。これは、他の開発者が持っているリポジトリを台無しにします-彼らはあなたの(書き換えられた履歴)変更を引っ張るときに難しいことをしなければなりません。

[#6:ありがとう@toxalot!]


#6の場合、はい、履歴を書き換えることができますが、ローカル履歴のみです。パブリックリポジトリにプッシュされたら、履歴を書き換えることは非常に悪い考えです。
トキサロット
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.