フォークについて
他のユーザーのプロジェクトに投稿したいが、そのリポジトリへの書き込みアクセス権がない場合は、"フォークと pull request" のワークフローを使用できます。
フォークとは、元の "上流" リポジトリとコードと可視性の設定を共有する新しいリポジトリです。 多くの場合、フォークは、上流リポジトリに再提案する前に、アイデアや変更に繰り返し取り組むために使用されます。たとえば、オープンソース プロジェクトや、ユーザーが上流リポジトリへの書き込みアクセス権を持っていない場合などです。
フォークから上流リポジトリに pull request を送信することで、投稿できます。 詳しくは、「リポジトリをフォークする」を参照してください。
リポジトリをフォークする
このチュートリアルでは、Spoon-Knife プロジェクト (GitHub でホストされているテスト リポジトリ) を使用して、フォークと pull request のワークフローをテストします。
-
https://github.com/octocat/Spoon-Knife で
Spoon-Knife
プロジェクトに移動します。 -
ページの右上隅の [フォーク] を選択します。
-
[所有者] の下のドロップダウン メニューを選び、フォークされたリポジトリの所有者をクリックします。
Note
ユーザー名が淡色表示になっている場合、フォークが既に存在します。 その代わりに、既存のフォークを最新の状態にする必要があります。 詳しくは、「フォークを同期する」を参照してください。
-
既定では、フォークの名前はその上流リポジトリと同じです。 必要に応じて、[リポジトリ名] フィールドに名前を入力すると、フォークをさらに区別できます。
-
必要に応じて、[説明] フィールドにフォークの説明を入力します。
-
必要に応じて、 [DEFAULT ブランチのみをコピーする] を選びます。
オープンソース プロジェクトへのコントリビューションなど、多くのフォーク シナリオでは、既定のブランチのみをコピーする必要があります。 このオプションを選ばないと、すべてのブランチが新しいフォークにコピーされます。
-
[フォークの作成] をクリックします。
Note
上流リポジトリから追加のブランチをコピーする場合は、[Branches] ページから行うことができます。 詳しくは、「リポジトリ内でブランチを作成および削除する」を参照してください。
フォークの複製
Spoon-Knife リポジトリのフォークが正常に生成されましたが、現時点では GitHub Enterprise Server にのみ存在しています。 プロジェクトで作業できるようにするには、コンピューターに複製する必要があります。
フォークは、コマンド ライン、GitHub CLI、または GitHub Desktop を使用して複製できます。
-
GitHub Enterprise Server で、Spoon-Knife リポジトリの自分のフォークに移動します。
-
ファイルの一覧の上にある [コード] をクリックします。
-
リポジトリの URL をコピーします。
-
HTTPS を使ってリポジトリをクローンするには、[HTTPS] の下の をクリックします。
-
Organization の SSH 認証機関から発行された証明書などの SSH キーを使ってリポジトリをクローンするには、 [SSH] をクリックしてから、 をクリックします。
-
GitHub CLI を使ってリポジトリをクローンするには、 [GitHub CLI] をクリックしてから、 をクリックします。
-
-
[ターミナル][ターミナル][Git Bash] を開きます。
-
カレントワーキングディレクトリを、ディレクトリをクローンしたい場所に変更します。
-
「
git clone
」と入力し、既にコピーした URL を貼り付けます。 次のようになるはずです。YOUR-USERNAME
を自分の GitHub Enterprise Server のユーザー名に置き換えてください。git clone https://HOSTNAME/YOUR-USERNAME/Spoon-Knife
-
Enter キーを押します。 これで、ローカルにクローンが作成されます。
$ git clone https://HOSTNAME/YOUR-USERNAME/Spoon-Knife > Cloning into `Spoon-Knife`... > remote: Counting objects: 10, done. > remote: Compressing objects: 100% (8/8), done. > remove: Total 10 (delta 1), reused 10 (delta 1) > Unpacking objects: 100% (10/10), done.
GitHub CLI の詳細については、「GitHub CLI について」を参照してください。
フォークのクローンを作成するには、--clone
フラグを使用します。
gh repo fork REPOSITORY --clone=true
-
[ファイル] メニューの [リポジトリの複製] をクリックします。
-
クローンしたいリポジトリの場所に対応するタブをクリックしてください。 URL をクリックして、リポジトリの場所を手動で入力することもできます。
-
リポジトリの一覧から、クローンするリポジトリをクリックします。
-
リポジトリをクローンする先のローカル ディレクトリを選ぶには、[ローカル パス] フィールドの横にある [選択] をクリックし、そのディレクトリに移動します。
-
[リポジトリのクローン] ウィンドウの下部にある [クローン] をクリックします。
作業のためのブランチの作成
プロジェクトに変更を加える前に、新しいブランチを作成してチェックアウトする必要があります。変更を独自のブランチに保持することで、GitHub Flow に従い、今後も同じプロジェクトに貢献しやすくなります。 詳しくは、「GitHub フロー」を参照してください。
git branch BRANCH-NAME
git checkout BRANCH-NAME
git branch BRANCH-NAME
git checkout BRANCH-NAME
GitHub Desktop でブランチを作成および管理する方法について詳しくは、「GitHub Desktop でのブランチの管理」をご覧ください。
変更の作成とプッシュ
Visual Studio Code などのお気に入りのテキスト エディターを使用して、プロジェクトにいくつかの変更を加えます。 たとえば、index.html
のテキストを変更すると、GitHub ユーザー名を追加できます。
変更を送信する準備ができたら、変更をステージングしてコミットします。 git add .
は、次のコミットにすべての変更を含める必要があることを Git に指示します。 git commit
は、これらの変更のスナップショットを取得します。
git add .
git commit -m "a short description of the change"
git add .
git commit -m "a short description of the change"
GitHub Desktop での変更のステージングとコミットの方法について詳しくは、「GitHub Desktop でプロジェクトの変更をコミットしてレビューする」をご覧ください。
ファイルをステージングしてコミットすると、基本的に Git に「変更のスナップショットを作成してください」と Git に指示したことになります。 引き続き変更を加え、より多くのコミットのスナップショットを作成できます。
現時点では、変更はローカルにのみ存在します。 変更を GitHub Enterprise Server にプッシュする準備ができたら、変更をリモートにプッシュします。
git push
git push
GitHub Desktop で変更をプッシュする方法について詳しくは、「GitHub Desktop から GitHub に変更をプッシュする」をご覧ください。
pull request の作成
やっと、メイン プロジェクトに変更を提案する準備ができました。 これは、他の誰かのプロジェクトのフォークを生成する最後のステップであり、間違いなく最も重要です。 コミュニティ全体に利益をもたらすと感じる変更を加えた場合は、ぜひ貢献することを検討してください。
そのためには、プロジェクトが存在する GitHub Enterprise Server のリポジトリに進みます。 この例では、https://github.com/<your_username>/Spoon-Knife
です。 自分のブランチが octocat:main
よりも 1 コミット分進んでいることを示すバナーが表示されます。 [貢献] をクリックし、 [Open a pull request](pull request を開く) をクリックします。
GitHub Enterprise Server を使用すると、フォークと octocat/Spoon-Knife
リポジトリの違いを示すページが表示されます。 [pull request の作成] をクリックします。
GitHub Enterprise Server を使用すると、タイトルと変更の説明を入力できるページが表示されます。 そもそもこの pull request を行う理由について、できるだけ多くの有用な情報と根拠を提供することが重要です。 プロジェクトの所有者は、変更が自分が考えるほどすべてのユーザーにとって役に立つかどうかを判断できる必要があります。 [pull request の作成] をクリックします。
フィードバックの管理
pull request は検討の対象となります。 プロジェクト所有者が pull request を拒否したり、リクエストが行われた理由の詳細を求めても、気を悪くしないでください。 プロジェクト所有者が pull request をマージしないことを選択した場合でも、変更はフォークに引き続き存在します。 他の誰かがあなたのフォークを元のプロジェクトよりもはるかに価値があると思うかもしれません。
プロジェクトの検索
正常にリポジトリをフォークし、リポジトリに貢献しました。 引き続き貢献をお願いします。