GitHubプロジェクトをフォークして名前を変更する場合の最適なワークフロー
Githubの既存のオープンソースプロジェクトのフォークを操作するための最適なワークフローを見つけようとしています。既存のプロジェクトを取得して大幅な変更を加えたいのですが、この場合はそれをAndroidに移植し、特定のAndroidのみの機能を追加します。以下を満たすために：
- 元のコードが更新されると、パブリックリポジトリから新しいAndroidポートに変更をプルできるようになります。
- Androidポートだけに適用できないバグを修正すると、元のプロジェクトへの変更を（プルリクエストを介して）要約できるようになります。
- プロジェクトの名前を変更した別のバージョンを用意して、それがAndroidポートであることを明確にします。フォークの名前を変更することを検討しましたが、Githubからこれを行うことについて大きな警告が表示されました。
私の最初の考えは、元のプロジェクトをフォークしてから、フォークをフォークして名前を変更し、次のリポジトリを作成することです。
original-author/projectA
nicstrong/projectA
nicstrong/projectA-Android
これにより、ローカルリポジトリlocal/projectA-Androidで作業できるようになります。nicstrong/ projectA-Androidへの変更をプッシュします。次に、元のプロジェクトから更新するために、nicstrong/projectAをoriginal-author/projectAから最新のものにリベースしてから、nicstrong/projectAからlocal/projectA-Androidにフェッチ/マージすることができます。
私の質問は次のとおりです。
- 私はGit全体にまったく慣れていません。これは良いアプローチのように見えますか？または、このシーンリオを処理するためのより良いワークフローはありますか？
- 元のプロジェクトのプルリクエストを設定できるように、projectA-Androidからnicstrong/projectAへのプッシュをどのように処理しますか？
1 /はい、これが最も安全なアプローチのようです。nicstrong/projectAにバックポートする変更は、original-author/projectAと同じ構造のプロジェクトに含まれるためです。
つまり、元の作成者のプロジェクトを反映したプロジェクトに参加するため、プルリクエストを整理しやすくなります。
2/nicstrong/projectA-Androidで大規模なリファクタリングが行われている場合は、backportブランチを作成し、backportブランチへの多数の変更から必要なものを慎重にマージまたはチェリーピックします、次にそのブランチをnicstrong/projectAにプッシュします。
（つまり、nicstrong/projectAのリモートとしてnicstrong/projectA-Androidを追加したことを意味します）
Gitリポジトリの名前は、リモートの名前に大きく依存しています。先に進んでクローンを作成し、新しいリモコンを（別の名前で）追加して、そこにプッシュし始めます。もちろん、その時点で、問題なくプロジェクトディレクトリの名前を変更できます。