最終更新日:2019年3月5日 11時23分閲覧回数:3628

ド素人によるGitHub上でのフォークとファイル修正とプルリクエストまでの覚書

この記事はド素人によるGitHubの覚え書きです。

はじめに

昨年GitHubにアカウントを持ったものの、理解が覚束ない現状を変えるべく、今春は気合を入れてGitとGitHubの学習に挑んだ。解説サイト巡礼の旅を続けて半月ほど経過し、ようやく“分からないところが分からない”レベルから離脱しかかったことから、分かる範囲で分かったことを覚書する個人的な学習ノート第一弾。

基本事項

  • GitとGitHubは似て非なるもの。
  • GitHubはあくまでもWEBサービスである。
  • 単なるファイル修正だけならば、GitHubだけでも可能。
  • 無料でGitHubを利用する時は必然的にOSSと化す。
  • GitとGitHubの目的は「いつ誰が何をどのように編集したか」を管理すること

1. GitとGitHubの成り立ち

「破棄したはずの文書データが担当者の個人用PCに残っていた」という問題や、「同じ内容なのに金額の異なる復数の契約書が見つかった」という問題が巷を賑わしているように、デジタルデータは紙とは異なり、復数のバージョンを作りやすい。 ↓ ソフトウェア開発でも、復数の開発者が同時並行して作業することが多い。 ↓ いつ、誰が、何を、どのように追加変更したか分かり、バックアップもできる仕組みがあると良いというリクエスト多数。(特にLinuxの開発者) ↓ 「Git」の誕生。(2005年12月)

Git(ギット)は、プログラムのソースコードなどの変更履歴を記録・追跡するための分散型バージョン管理システムである。Linuxカーネルのソースコード管理に用いるためにリーナス・トーバルズによって開発され、それ以降ほかの多くのプロジェクトで採用されている。 
↓ Gitを使った開発の中核的なものがあると良いというリクエスト多数。 ↓ 「GitHub」の誕生。(2008年4月)
GitHub(ギットハブ)はソフトウェア開発プロジェクトのための共有ウェブサービスであり、Gitバージョン管理システムを使用する。 
要するに、GitHubとは、Gitのハブ。つまり、「Gitを使って開発している人たちの集まるところ」である。
ハブ【hub】の意味
  1. 車輪の中心部。また、自動車の車輪を取り付ける部分の円板や、航空機用エンジンのプロペラを取り付ける金具。
  2. 中心。中核。
  3. コンピューターシステムで、複数の端末を集めて連結する中継器。LANなどを組むのに使われ、減衰した電気信号を復元する機能などをもつ。集線装置。

2. GitHub利用概要

  1. 会員登録
  2. 既存リポジトリのフォークを作成
  3. フォークしたリポジトリのファイルを修正
  4. 修正後のファイルを新規ブランチとして登録
  5. 新規ブランチの内容をプルリクエスト
  6. 内容に問題がなければマージする
  7. フォーク元の既存リポジトリに対してプルリクエスト
  8. フォーク元からの反応を待つ

3. GitHub にメンバー登録する。

名前、メールアドレス、パスワードを登録する。詳細は参考リンクを参照。

4. 自分のアカウントにリポジトリを用意する

リポジトリ(repository)とは、倉庫・保管場所・集積地という意味で、ソフトウェア本体及び付随するデータベースのこと。 GitHubでは2種類の作り方がある。(ソフトウェアは沢山のソースコードの集まりである故に、このような命名が成されたと思われる)

(4-a) GitHub上にリポジトリを作る

GitHub 上で新たに開発プロジェクトを起ち上げる場合に行う。詳細は参考リンクを参照。

(4-b) 既存のリポジトリをGitHub上でフォークする

GitHubにはフォーク(Fork)という分派を作る機能がある。 フォークを行った人が管理者になるので、本家リポジトリの分派を作る場合や、他言語化の際には必須。 クローンとの違いは、GitHub 上に痕跡が残るか否か。GitHub はあくまでもWEBサービスなので 少し古いが、Netscape Navigator から Mozilla が分派して Firefox に至った流れを想像すると良いかもしれない。 既存リポジトリの画面右にある「Fork」ボタンを押す。
フォーク後のリポジトリは画面左上に「自分の名前/フォークしたリポジトリ名」で表示される。 開発者として参加する場合は、まずフォークしてからファイルの修正や追加等の作業を行うと良い。

5. GitHub の画面上でファイルを編集する

フォーク後、リポジトリ内にあるファイルの編集を行うだけなら、GitHub上で作業を進めることが可能。 「Code」タブにて当該ファイルを開き、画面右にあるEditアイコン(ペンの形)を押すと、ブラウザ上で編集可能になる。
「Edit file」タブを開いて適宜修正する。
「Preview changes」タブを開くと、どこを変更したかが視覚的に表示される。

6. 新規ブランチを作成して保存

自アカウント内のリポジトリに編集結果を保存する際、間違っていた場合に備えて、原本と編集用の最低2つの分岐を作る。この分岐のことを「ブランチ(Branch)」という。 今回のようにGitHub上で編集作業を行うと、保存時にブランチを作ることができる。 編集内容を確認したら、画面下にてコメントを記し、「Create new branch (以下略)」を選択。 適当な名称を記して「Propose file」ボタンを押す。

注意点

フォーク(Fork)
リポジトリの分岐。
自分と他者がそれぞれリポジトリを管理している状態。
ブランチ(Branch)
自分のリポジトリ内での分岐。
自リポジトリ内で原本と編集用を分けること及びその名称。
「ブランチを切る」「ブランチを作る」ともいう。

7. 自アカウント内でプルリクエスト

GitHub のリポジトリに変更点を連絡することを「プルリクエスト(Pull requests)」という。 これは他の開発者と議論し、必要に応じて追加修正を行うための機能である。 GitHub の画面上でファイル編集&ブランチ作成を行うと、次の画面でプルリクエストができるので、コメントを記してから「Create pull request」を押す。

注意点

要するに「ここを変更して改善しました。ご確認後、貴リポジトリにご採用頂ければ幸いです」の略がプルリクエスト

8. 自アカウント内で当該ファイルをマージ(又はリベース)する

ファイル編集&ブランチ作成&プルリクエストを行った後、内容に問題がなければマージ(Marge)又はリベース(Rebase)を行う。 マージとリベースはどちらもブランチに制式採用することを意味し、保存内容とその後の処理が異なる。 素人はマージを選ぶ方が無難。
プルリクエストの画面に、緑色のアイコンとチェックマークが入り、「元のブランチとの間にコンフリクトはありません」のメッセージが出ていたら、以下の3つから選んでマージ又はリベースを行う。
Create a merge commit
ブランチの内容が元のブランチに追記される(履歴の詳細が残る)
Squash and merge
ブランチの変更点が元のブランチで統合される(履歴の詳細が残り、統合される)
Rebase and merge
ブランチの一つのコミットをリベースしてからマージする(一つの履歴に統合される)
コンフリクト【conflict】の意味
  1. 意見・感情・利害の衝突。争い。論争。対立。
  2. コンピューターで、複数のタスクが同時に同じファイルやメモリ領域を利用して競合する状態。システムダウンを引き起こす要因となる。
conflict(コンフリクト)の意味 - goo国語辞書
マージ(又はリベース)後のトップページ。変更が反映されているのが分かる。

9. フォーク元にプルリクエスト

フォーク元のリポジトリに自アカウントでの変更を反映してもらいたい場合に行う。 (フォーク元とは袂を分かつこととなった場合は行わなくても良い) 自アカウント内でマージが完了した後、フォーク元のリポジトリに移動。 Codeタブの「New pull request」ボタンを押す。
次の画面で「compare across forks」のリンクを押す。
  1. 左側の「base fork」にフォーク元、「base」に対象ブランチ名を指定。
  2. 右側の「head fork」に自アカウントのリポジトリ、「compare」に先ほどマージしたブランチ名を指定。
  3. 簡単な英語でプルリクエスト用のコメントを記す。(開発者が全員日本人なら日本語で桶)
画面右下の「Allow edits from maintainers」にチェックを入れると、自アカウントのブランチに対し、フォーク元の管理者が書き込めるようになる。
フォーク元へのプルリクエスト完了後の画面。 後はフォーク元の開発者からの意見及び管理者からのマージを待つ。

10. フォーク元の反応を待つ

フォーク元にプルリクエストをした後は、他の開発者からのツッコミや質問に対応する必要があるため、こまめにチェックしよう。
フォーク元がマージした直後。 その後、特に問題がなければこのプルリクエストはclosedされ、フォーク元のリポジトリには自分の変更が採用されている。 つまり、胸を張って「私は●●というOSSプロジェクトに携わっています」と名乗れる訳だ。
なお、管理者がマージを行うとマージ完了メールが届く。
今回のように、ブラウザでGitHubにログインし、簡単なファイル修正を行う方法は、組織内で共通のメール雛形や書類を作るにも向いているかもしれない。OSS的にどうかは分からないが。

コメント

当フォームより収集される個人情報は、返信を要する際に使用されるものであり、法令に基づく行政機関等への提供を除き、ご本人の同意を得ずに第三者に提供することはありません。また、コメントが掲載される場合であってもメールアドレスが本サイト内に記載されることはありません。