フォークを使用して内部ソースを記述する
書き込みアクセス権を持っていないリポジトリ内にあるコードを変更する必要があるとき、リポジトリをフォークします。
書き込みアクセス権を持っていない場合は、そのリポジトリに参加しているチームの一員ではないことになりますが、あなたはなぜそのコード リポジトリを変更するのでしょうか?
仕事で何かを改善するとき、技術的な理由が求められる傾向があります。
既存の機能に貢献したり、既存の機能を改善したりすると、ソリューションを実装したり、機能を拡張したりするための、さらに優れた方法が見つかることがあります。
次の状況では、リポジトリをフォークできます。
- 変更を加える必要がある。
- 優れたプロジェクトであり、場合によってはその採用を望む。
- プロジェクトの出発点として、そのリポジトリにあるコードをいくつか使用してみたい。
ソフトウェア チームには、自分たちのソフトウェア プロジェクトだけではなく、すべてのプロジェクトに内部的に貢献することをお勧めします。
フォークは、内部オープン ソースの文化を育むための優れた方法です。
フォークは、Azure DevOps Git リポジトリに最近追加されたものです。
このレシピでは、既存のリポジトリをフォークし、pull request を使用してアップストリームで変更に貢献する方法について説明します。
開発の準備
フォークは、アップストリームの (元の) リポジトリのすべてのコンテンツから開始します。
Azure DevOps でフォークを作成するときは、すべてのブランチを含めるか、既定のブランチにのみ制限することができます。
フォークによって、フォークされているリポジトリのアクセス許可、ポリシー、またはビルド定義がコピーされることはありません。
フォークが作成された後は、pull request を開始しない限り、新しく作成されたファイル、フォルダー、ブランチがリポジトリ間で共有されることはありません。
pull request は、フォークからアップストリームまたはアップストリームからフォークのどちらの方向にも作成することができます。
pull request の最も一般的な方法は、フォークからアップストリームです。
方法
[フォーク] ボタン (1) を選択したら、フォークの作成が必要なプロジェクトを選択します (2)。 フォークに名前を指定して、[フォーク] ボタン (3) を選択します。
フォークの準備ができたら、コマンド ラインまたは Visual Studio などの IDE を使用して複製します。 そのフォークが、複製元のリモートになります。 便宜上、アップストリーム リポジトリ (フォーク元の場所) を「アップストリーム」という名前のリモートとして追加する必要があります。 コマンド ラインで、次のように入力します。
git remote add upstream {upstream_url}main で直接作業することは可能です。このフォークがリポジトリのコピーとなります。 ただし、引き続きトピック ブランチで作業することをお勧めします。 これにより、複数の独立したワークストリームを同時に維持することができます。 また、後で変更をフォークに同期する場合は、混乱が軽減されます。 通常どおり、変更を加えてコミットします。 改良を終えたら、それを元の場所 (フォーク) にプッシュします。
pull request を、フォークからアップストリームに開きます。 アップストリームのリポジトリで、レビュー担当者とビルドに必要なすべてのポリシーが適用されます。 すべてのポリシーが満たされたら、PR を完了することができます。変更は、アップストリーム リポジトリの永続的な一部になります。
PR がアップストリームで承認されたら、必ず、リポジトリの最新状態がフォークに反映されるようにします。 アップストリームの main ブランチを再配置することをお勧めします (main がメインの開発ブランチであることが前提です)。 コマンド ラインで、以下を実行します。
git fetch upstream main git rebase upstream/main git push origin
Git に関する詳細については、次をご覧ください。