【OSS活動入門】OSS活動を始めるためのGitHub基本操作（フォークからプルリクまで）
専門的な知識や高度な技術を使わなくても、小さなところからOSS活動できるように記事を作成しました。
OSS活動を始めようと思っている方の参考になりましたら幸いです🙇♂️
記載していること
- リポジトリを自分の作業場に持ってくる
- 最初の貢献（コントリビュート）に挑戦する
- OSS活動を始めるためのGitHub基本操作について
リポジトリを自分の作業場に持ってくる
まずは、OSS開発の第一歩である「フォーク」と「クローン」をやってみます。
フォーク(Fork)する
ここでは自分の「作業場」となるリポジトリを作成するために、対象のリポジトリを「フォーク」します。
フォークすることで、リポジトリの完全なコピーが自分のGitHubアカウントで管理できるリポジトリとして作成されます。
- 対象のリポジトリにブラウザでアクセスする
- 画面の右上にある「Fork」ボタンをクリックする
- 「Create fork」ボタンをクリックする
- 任意のリポジトリ名を入力できる
- ここではフォーク元のリポジトリと同じ名称を使用した
- 自身のリポジトリに追加される
- 例）
https://github.com/{your_name}/{repository_name}
- 例）
今後、変更はこのリポジトリに対して行います。
クローン(Clone)する
ここではフォークして作成された自分のリポジトリを、PCのローカル環境にダウンロードします。
- フォークした自分のリポジトリにアクセスする
- 「<> Code」ボタンをクリックし、表示されたURLをコピーする
- この記事ではHTTPS形式のURLを選択する
- PCでターミナル（またはコマンドプロンプト）を開く
- 作業したいディレクトリに移動して、以下のコマンドを実行する
$ git clone コピーしたURL
フォークを同期する
すぐには差分は発生していないかと思いますが元のリポジトリ（フォーク元のリポジトリ）で変更があった場合に、それを自分の作業場にも反映できるように同期する手順についても確認しておきます。
同期する方法はいくつかあります。
ここでは2つとりあげます。
- GitHubのGUIでフォークを同期する方法
- コマンドラインからフォークのブランチを同期する
GitHubのGUIでフォークを同期する手順
- GitHub でアップストリームリポジトリと同期するフォーク先のリポジトリのメインページにアクセスする
- コードが表示されているページで、ブランチを選択するボタンの近くに、本家のリポジトリとの状態を示すメッセージが表示される
- もしあなたのフォークが本家より遅れている場合、メッセージが表示される
- その隣の
[Sync fork]というボタンをクリックすると、プルダウンメニューが表示される - ここに本家から取り込まれる変更内容の概要が表示されるので、内容を確認して緑色の
[Update branch]ボタンをクリックする
コマンドラインからフォークのブランチを同期する手順
本家リポジトリの変更を取り込めるように設定 (Upstream設定)します。
- ターミナルを開き、クローンしたディレクトリに移動する
# クローンしたディレクトリに移動する cd {ディレクトリのパス} - リモートリポジトリの一覧を確認する
$ git remote -v origin https://github.com/{your_name}/{repository_name}.git (fetch) origin https://github.com/{your_name}/{repository_name}.git (push) - フォーク元リポジトリにブラウザでアクセスする
- 「<> Code」ボタンをクリックし、表示されたURLをコピーする
- フォーク元のリポジトリをリモートリポジトリに追加する
// 参考 $ git remote add upstream https://github.com/ORIGINAL-OWNER/ORIGINAL-REPOSITORY.git // コピーペーストを利用して作成するコマンド $ git remote add upstream {コピーしたURLをペースト} - リモートリポジトリの一覧を確認する
$ git remote -v origin https://github.com/{your_name}/{repository_name}.git (fetch) origin https://github.com/{your_name}/{repository_name}.git (push) upstream https://github.com/{target_name}/{repository_name}.git (fetch) upstream https://github.com/{target_name}/{repository_name}.git (push)
Upstream設定が完了していれば、以下のコマンドを実行します。
# 本家の最新の状態に更新
git fetch upstream
git checkout main
git merge upstream/main
upstreamとはどういう意味か？
upstreamとは「上流」という意味の英単語です。
upstreamはOSS開発において慣習的に使用されていて「本家」のリポジトリを指します。
本家の変更（川の上流からの流れ）を取り込むために設定します。
upstreamとoriginの違い
originはgit cloneを実行したときにクローン元のリポジトリに対して自動的に付けられるデフォルトの名前です。
今回のフォークしてからクローンするワークフローでは、origin は自分自身のGitHub上のリポジトリになります。
最初の貢献（コントリビュート）に挑戦する
いきなり大きな変更をすることは難しいと感じます。
なので簡単なことから始めて、一連の流れを体験してみましょう。
issueを立てる
OSS開発では、何か作業を始める前に「こんな問題がある」「こんな機能を追加したい」といった提案を issueとして登録します。
対応することが明確になるように、なるべく小さな内容で対応内容がわかるようにissueを立てます。
たとえば、練習レベルの簡単なテーマ案を考えてみるとこんなイメージです💡
- ドキュメントの改善提案
- README.md ファイルを読んでみて、誤字脱字を見つけたり、「この説明を追記した方が分かりやすいのでは？」といった改善案をIssueとして立ててみる
- 簡単な改善提案
- アプリを動かしてみて、「ここのテキストを少し変えたい」「このボタンの色を変えてみてはどうか」といった、簡単な改善を提案してみる
実際にissueを立ててみます。
- フォーク元のリポジトリにブラウザでアクセスする
- フォーク元のリポジトリの 「Issues」タブを確認して、既に同じ内容のissueがないか確認する
- 「New issue」ボタンをクリックする
- TitleとDescriptionを入力する
- Issueのタイトルはどんな対応が必要かイメージできるようにわかりやすく示します
- Issueの説明はどこを修正したいのか、修正の意図や目的をわかりやすく示します
- 可能ならIssueの中に具体的な修正箇所や修正例を挙げると意図が伝わりやすくスムーズなコミュニケーションが可能です
- 「Create」ボタンをクリックしてIssueを作成する
簡単な修正でプルリクエストを送ってみる
Issueを立てたら、次はコードの修正をします。
変更内容やコミットメッセージは、フォーク元のリポジトリをメンテナンスしている人が確認することがあります。
変更したい意図や作業の記録は読みやすいものを心がけましょう。
様々なGitクライアントがあるので、詳細なGit操作はここでは説明しません。
ブランチ (Branch) を作成する
修正作業は、必ず新しいブランチを作成して行います。
フォークしたリポジトリのmainブランチで直接作業しないようにするためです。
? なぜmainブランチで直接作業しないのか？
フォークしたリポジトリのmainブランチは、本家の変更をいつでもスムーズに受け入れられる状態にしておく必要があるためです。
そのため、機能開発を行うときはブランチをわけて作業を行い、mainブランチとは切り離しておくことが重要です。
以下、リポジトリとブランチの対応イメージを図で示します。
ブランチ名は、fix/readme-typo (READMEのタイポ修正) や feature/add-new-color-theme (新しいカラーテーマの追加) のように、作業内容がわかる名前にしておくと、issueで目的から離れにくい発散しにくい作業にまとまられそうです。
今回私は対応内容に合わせて以下のようにブランチ名を検討しました。
-
fix/readme-typo-3- 「fix/」で修正系の作業であることを明示
- 「readme-typo」で内容を簡潔に表現
- 作成したissue番号の「3」を末尾につけて関連付け
コードを修正する
実際にissueに記載した内容に対応する作業を行います。
例えば、以下のような簡単な修正をイメージです。
- README.md の誤字を修正する
- コード内のコメントを追加・修正する
- アプリ内の表示テキストを少しだけ変更する
コミット (Commit) & プッシュ (Push)する
修正が完了したら変更内容を記録（コミット）します。
- この時にコミットメッセージを分かりやすく書くと自身の作業内容や意図が明確になります。
コミットしたら自分のリポジトリ（フォークしたリポジトリ）にアップロード（プッシュ）します。
- Upstream設定が完了している場合、プッシュ先の候補に
upstreamが表示されるかもしれません。プッシュするのは自分のリポジトリであるoriginになります。
# ご自身のGitHubリポジトリにプッシュコマンド例
git push origin <ブランチ名>
プルリクエスト (Pull Request) の作成する
プッシュが完了すると、自分のGitHubリポジトリのページに「Compare & pull request」というボタンが表示されます。
これをクリックし、プルリクエスト（「この変更を本家に取り込んでください」というお願い）を作成します。
このときプルリクエストの説明を具体的に書くと、レビューする側がわかりやすくなります。
- タイトルの書き方
- 何をしたのかが簡潔にわかるように書く
- 例）README.md のタイポを修正
- 内容の書き方
- どのIssueに対応するものか
- どのような変更をしたのか
- なぜこの変更が必要だと思ったのか
レビューへの対応
プルリクエストを送った後、メンテナーからコメントが付くことがあります。
- これはコードをより良くするための貴重なフィードバックです。
コメントには感謝を伝えましょう！（例: "Thank you for your review!"）
指摘内容について質問があれば遠慮なく質問して、よりよい開発にしていきましょう。
指摘を受けてコードを修正したら、「修正しました、再度確認をお願いします」と返信します。
OSS活動を始めるためのGitHub基本操作について
OSS活動はハードルが高く感じます。
ハードルが高く感じる理由として、「多くの知らないことが存在する状態」がひとつの原因と考えられます。
世界には自分より優秀なエンジニアが多いと感じることは日常茶飯事です。
自分が知らない高度に感じる技術で実現されているプロジェクトも多いです。
その中で「OSS活動を始める」ということは「多くの知らないことが存在する状態」です。
今回私が書いた記事でGitHubの基本操作について知り、「知らないこと」が少しでも減ったら嬉しい限りです。
専門的な知識や高度な技術を使わなくても、小さなところからOSS活動できるようにトライしてみましょう💡
記事の内容に不備や誤りがありましたら、コメントいただけますとありがたいです🙇♂️
参考記事など
参考になりました🙇♂️
Discussion