自分のニーズに合うように、オープンソース プロジェクトをフォークする必要があると真剣に考え始めています。元の作者にパッチを送りましたが、返事はかなり簡潔で、まあ、歓迎されませんでした。
とにかく。オープン ソース プロジェクトをうまくフォークするという質問を読みましたが、これは私のより具体的な質問には答えません。
ファイルはどうすればよいですか？
まず、元の Git リポジトリをそのまま使用するか、すべての履歴を破棄して新たに開始するか (" rm -rf .git && git init")? 次に、古い readme:s、以前のリリース情報、およびバージョン管理に関する意見はありますか?
当然、ライセンスと帰属は、ライセンスの要件に従って処理されます。
履歴は、ソース管理の最も重要な部分です。履歴を残して、自分の開発が始まった時点にラベルを付けるといいでしょう。
元の作成者にパッチを送り返す予定がない場合でもgit、素晴らしいローカル バージョン管理ツールになります。
以前に投稿された他のワークフローのいくつかへの補遺として、github に関するもう 1 つのクールな点:
git cloneローカルで新しいレポへの指示に従ってくださいプロジェクトの作成者からくだらない反応を受け取った場合、彼らはあなたの助けに値するものではなく、恩返しについてあまり心配する必要はないと思います。ただし、Fork Queue についてはステップ 4 に従ってください。あなたと一緒にプロジェクトに変更を加えている github の他の全員と最新の状態を保つことができます。
簡単な追加: 元の作成者から少し離れた作業を行いたい場合は、非常に簡単です: * 新しいブランチ ( git checkout -b my_branch_name) を作成し、そこで作業します。
* ブランチが目的の状態になったら、元のブランチに切り替え ( git checkout master)、変更をマージして( ) 戻すことができますgit merge my_branch_name。
* その後、それを github ( ) に戻すgit push origin masterか、または * 元の作成者用のパッチを作成します (いくつかのバージョンの を使用git format-patch)。
他の人が指摘しているように：あなたは本当に歴史を保つべきです。READMEとバージョン管理について：元のプロジェクトとの混同を避けるために、プロジェクトの名前を変更する必要があります。元のプロジェクトをほのめかす名前を使用できますが（ただし、潜在的な商標の問題に注意してください）、無礼にならないようにしてください。たとえば、元のプロジェクトの名前が「foo」の場合、プロジェクトに「foo-ng」（次世代）という名前を付けると、プロジェクトが他のプロジェクトよりも「優れている」と何らかの形で示されます。これが事実だと感じたとしても、そうしないでください。
READMEは、必要に応じて更新する必要があります。つまり、新しいプロジェクト名、それがプロジェクト「foo」のフォークであるという事実、そしておそらくそれがフォークしたポイントを文書化する必要があります。個人的には、ChangeLogsや同様の、より技術指向のドキュメントを保持し、必要に応じてそれらに追加しますが、「NEWS」スタイルのドキュメント、つまりエンドユーザーを対象としたドキュメントから始めます。
完全な書き換えを行う場合は、新しく初期化された git を使用してください。それ以外の場合は、クローンを作成してください。
実際に fork を行う (元のプロジェクトが中断したところから開始する) 場合は、必ず元のリポジトリのクローンを作成し、コミットを続行してください。これにより、元のリポジトリからの変更をマージできるだけでなく、元のプロジェクトの開発者がフォークからの変更を元にマージできるようになります。両方のプロジェクトがGithub上にある場合、このコラボレーションはさらに簡単になります (プル リクエスト)。
リポジトリに変更を加え、パッチまたはプルリクエストを送信する必要があるため、これは実際には非常に自然なことです。フォークは同じですが、別のプロジェクトとしてラベル付けされています。