目次
GitHub で他の人の Repository に参加する方法
ここでは、GitHub 上の他の人の Repository のソースを修正して、修正の取り込み依頼(PULL リクエスト) を送るまでの流れを書いています。
1. GitHub アカウント作ってログインする
ブラウザで自分の GitHub アカウントでログインします。
2. 自分の参加したい Repository に移動して Fork ボタンを押す
ブラウザで、クラウド上の自分の参加したい GitHub の Repository に移動して Fork ボタンを押すします。
これだけで、クラウド上の自分の Repository の下に、参加したい人の Repository が Fork されます。
この Fork という作業は、後でこの Repository に修正したコードをマージを要請することを前提とした作業になります。
ですので身元が明らかになるように、クラウド上の自分アカウントにログインしてからでなければ行うことができません。
自分のＰＣ上にいきなり「Fork」する事もできません。
クラウド上でのやりとりになります。
3. 自分のアカウントの下に Fork された Repository ができた事を確認する
ブラウザで、GitHub の 自分のアカウントの下に Fork された Repository ができた事を確認します。
Fork 元の Repository 名が apache/project1 であれば、myname/project1 と言う名前の Repository が自分のアカウントにできているはずです。(myname は自分の GitHub アカウント)
4. 自分のPC上に、Fork した Repository を Clone する
git clone https://github.com/myname/project1
上記を実行すると、自分のＰＣ上に、Repository がコピーされ、ソースファイルの編集が可能になります。
この時、ローカルブランチが一つ作られます。
clone 後、何も考えずにファイルの編集をはじめた場合でも、実はそのデフォルトのブランチの中で作業している事になります。
Clone 元の Repository が、何と言う名前のブランチをデフォルトとして使っているかは、 git branch で確認できます。
特に何も設定してないケースでは、GitHub で Repository を作った時にデフォルトで作られる master というブランチ名になっていると思います。
master は、その Repository の幹となるメインのブランチです。
但し Repository 側が複数のブランチを持っている場合は、デフォルトで clone されるブランチを変更する事が可能です。
(git の使い方のハードルが高いのは、特に引数を指定しない時に使われる”暗黙”の名前やコンセプトが所々に潜んでいてからかなと思ったり)
GitHub 上の Repository は、多くのケースで master ブランチとそこから派生した複数のブランチ（QA用だったり、Development 用だったり）を持っていますが、git clone した時にローカルに作られるのは、その Repository のデフォルトのブランチだけです。
例えば、以下のような例を考えます。
- Repository を作成、
masterブランチは、本番環境にデプロイするコードとし、そのブランチのソースは直接触らないようにする。 - 開発者向けには、
developmentというブランチを作り、最新の開発版のコードはdevelopmentブランチに置くようにする。適宜、developmentのコードをmasterにマージする。
この時、開発者が必要なコードは development ブランチのコードなので、git clone した時に、development ブランチの内容をclone したいはずです。
その場合は、default のブランチを development に設定しておく事で、開発者がその Repository を clone した時に、development のブランチの内容がローカル PC にコピーされる事になります。
default のブランチは、GitHub 上で変更できます。
5. ローカルPC上に作業用のブランチを作る
以下のコマンドを実行してと fork した Repository のデフォルトのブランチ から mylocalbranch という名前の作業用のブランチを作成します。
git checkout -b mylocalbranch
ブランチを作成すると、作成したブランチに切り替わります。
現在いるブランチは、以下のコマンドで確認できます。
$ git branch -a * mylocalbranch master remotes/origin/HEAD -> origin/master remotes/origin/master $
* の付いているのが現在、作業中のブランチになります。
純粋に自分のいるブランチだけ確認したい場合は
git branch
で表示できます。
このブランチは、後で明示的にクラウド上の Repository に Push しない限り、ローカルPC上にだけ存在するブランチになります。
ブランチは、元のソースから派生したソースコードになります。最終的にはこのブランチを派生元に「マージ」してもらう事を目指します。
修正するファイルは、数ファイルでも、「マージ」のリクエストを行う時は、このブランチの単位でマージリクエストをします。
ブランチ単位でマージのリクエストを本家 (Fork 元) に出しますが（このリクエストを「PULL リクエスト」と言ったり PR と言います）、実際にはファイルの差分が比較されて、更新のあったファイルだけが本家に取り込まれます。
ここでは、mylocalbranch というシンプルな名前を使用しましたが、ブランチ名には、"/" も使えます。
そのため例えば issue 番号 1234 に対しての fix で test.json を修正するという意味で「fix/#1234/test-json」という情報を詰め込んだブランチ名も作る事ができます。
実際のプロジェクトでは、ブランチ名で「あ。このブランチは xx を修正したんだな」とブランチ名から予測できる方が親切です。
このブランチは、後で PULL リクエストが Fork 元にマージされた後は、消す事になります。
git branch コマンドでは、デフォルトのブランチ（あってる？ひょっとして自分が現在いるブランチでは？）から、新しいブランチが作られますが、デフォルト以外の特定のブランチから新しいローカルのブランチを作りたい場合は以下のようにします。
git checkout -b <新しいローカルのブランチ名> origin/<派生元のブランチ名>
checkout は、<派生元のブランチ> の内容をコピー (checkout) して、<新しいローカルのブランチ> を作るイメージになります。
ここで、origin って何だろう？となりますが、origin は、「リモート」にある Repository の名前で、「リモート」とはクラウド上にあるリポジトリーの事を指します。
クラウド上のリポジトリから、git clone で、ローカルのリポジトリを作成した時に、クラウド上のリポジトリに origin という名前が自動で付けられます。
また、ローカル･ブランチを新しく作った事で、複数のローカル･ブランチを持つ事になります。
その他、よく使うコマンド
間違って作成したブランチを削除したい場合は以下のコマンドで削除できます。
git branch -d <ブランチ名>
6. 修正を作成する
ここでは、test.json というファイルを修正した事にします。
7. 修正を作業用ブランチにコミットする
「コミット」は、ローカルの Repository に対して変更を確定する作業になります。
編集した「test.json」を、ローカルの Repository に対して、確定した変更として「コミット」する。変更確定を登録するような作業になります。
git add test.json
git commit -m "small changes"
git add <ファイル名> は、<ファイル名> を、コミット予定のリストに追加する事を指します。
はじめに疑問に思うのは「何故、add と commit でわざわざ２段階の作業をしているのか？」だと思います。
もちろん、一個一個、修正したファイルを手作業で直接コミットしても良いですが、コミット予定ファイルのリストを作って置いて、後でそのリストに載っているファイルを一気にコミットできるようにするため、ワンクッションを設けているようです。
git commit -m "small changes" の -m の部分は、後で Fork 元に PULL リクエストをした時に、以下のように PULL リクエストの下に小さく表示されます。
このコメントは、ソースコードについて回り、クラウド上に上がった際は、みんなが読む所なので、あまり適当な事を書くと恥ずかしい事になるので注意します。何の変更を行った commit なのかわかるようなメッセージにもしておきましょう。
以下は、git commit -m "added new keys" とやった場合の表示です。
8. 自分のリポジトリ (この場合 myname/project1 ) に PUSH リクエストを送る
PUSH リクエストは、ローカルの Repository を、リモートの Repository （ここでは「origin」) に送りつける作業になります。
ローカルの Repository と言っても「ブランチ」に分かれているので、ローカル Repository のどのブランチを”上に上げる” (push する）か、指定する必用があります。
git push origin <ブランチ名>
以下の例は「mylocalbranch」がブランチ名です。
git push origin mylocalbranch
これで、「リモート」(GitHub 上のリポジトリ) である origin に対して、 mylocalbranch というブランチが、push された事になります。
ただし、mylocalbranch は、ローカルで作られたものなので、origin に mylocalbranch というブランチが新しく作られる事になります。
新しいブランチが origin にできるだけなので、 origin の Repository のどこかを破壊するという事にはなりません。
もし origin の既存のブランチを指定した場合は、 origin のブランチはアップデートされる事になります。
なお、fork 元 （この例では true_orign はアップデートされませんし、そもそも権限が無いので fork 元は普通にはアップデートできず、PULLリクエストを送って変更をマージしてもらうようにお願いする必用があります。
9. ブラウザで GitHub の自分のリポジトリに行くと、Fork 元の Repository に、PULL リクエストが送れるようになっている。
Fork 元の Repository 名とブランチを指定し、そこに対して PULL リクエストを送ります。
この作業はブラウザ上からのみ行えます。
「プルリク」と言う人もいれば、PRと書いて「ピーアール」と言う人もいます。
PULL リクエストは、相手の Repository のブランチのコードを、自分の持っているブランチのコードで上書きする事を依頼する作業です。
PULLリクエストは、リモート（クラウド上）の Repository 間で行える作業で、「ローカル」Repository から「リモート」Repository に直接 PULL リクエストはできません。
これは、ローカルからのリクエストだと、身元のよくわからない人からの謎のリクエストになってしまうからだと思われます。
ローカルからの PULL リクエストだったとしても userid / password を GitHub に送って認証をしてもらって token を取得し、その Token を相手に送って確認してもらえれば、GitHub のユーザーの特定ユーザーからの PULL リクエストである事の身元確認は理屈的には可能ですが、そもそもクラウド上の Repository からの PULL リクエストで無いと、相手からマージを要求されているコードの内容がわからないためだと思われます。
また、事前にブランチ間の差分はチェックされ、差分が何もないと、以下のようにPULL リクエストが送る事ができません (There isn't anything to compare)
また、「PULL 」と言った時に、
- 「自分のローカル Repository をリモートの Repository で上書きする」
- 「他人の リモート Repository に、自分のリモート Repository の内容のマージを依頼する場合」
の2つがあります。「PULL リクエストを送る」は後者の場合の文脈のみで使われます。
Fork元のブランチの内容で、ローカル PC上のブランチの内容をアップデートする
Fork 元のブランチ(リポジトリ）のソースコードがアップデートされても、クラウド上の自分の GitHub 上にある Fork したブランチ(リポジトリ）の内容はアップデートされません。
そのため、複数人で作業を行っている場合は、Fork 元のブランチの内容と自分の作業中のブランチのソースコードの同期作業を定期的に行い、自分の持っているコードが時代遅れにならないようにする必要があります。
ここでは、Fetch 元に development というブランチがあり、ローカル PC 上にも development というブランチがあるとします。このローカル PC のブランチを Fetch 元のブランチの最新のコードでアップデートします。
1. Fork 元の Repository を、"リモート"として追加する
ローカル PC 上で、Fork 元になっている Repository を、「リモート」として追加します。
「リモート」は、はじめは origin という名前が定義されているはずですが、それはクラウド上の自分の GitHub アカウントの下の fork された Repository を指します。
fork されたプロジェクトをローカル PC に clone した時に clone 元 (つまり fork された Repository) を指す名前として origin が自動で作られています。
origin という名前に https://github.com/myname/project1 というような自分の GitHub 上の URL が結びついているとイメージになります。
なお origin という名前は、URL に紐付くもので、自分のローカル Repository 上でそう呼んでいるだけで、他の人は test と名付けている可能性もあります。
origin という名前は誰から見ても同じグローバルな名前では無く、デフォルトで origin という名前が使わているだけで、default 値であるため、ほとんどのユーザーで同じ名前になっていますが、それぞれのユーザー (ローカル Repository) の中でだけで有効な名前です。
ここでは、origin の名前は既に使われているので、それ以外の名前を付ける必用があります。
ここでは fork 元なので true_origin と名付けます。コマンドのフォーマットは以下の通りになります。
git remote add <追加したいリポジトリーの別名> <追加したいリポジトリーの URL>
true_originという名前で https://github.com/apache/project1 という GitHub 上のレポジトリーの URL を登録する場合は以下になります。
git remote add true_origin https://github.com/apache/project1
これで、リモートとして origin と true_origin の 2つがローカルＰＣ上に定義されているはずです。
以下のコマンドで確認できます。
git remote
2. true_origin から fetch を行う
やらなくても 3 はできますが、ローカル PC に true_origin の全てのブランチを fetch (ダウンロード) しておく作業です。
これを行っておくと、タブキーで、true_origin <branch 名> のような時に <branch 名> を補完してくれるようになるので便利です。
※ fetch は merge までは行わないので、既存のローカルブランチに影響は出ません。
git fetch true_origin
これで、git branch -a を実行した時に remotes/origin/<ブランチ名> に加えて remotes/true_origin/<ブランチ名> も出てくるようになっているはずです。
3. ローカルのブランチを、Fetch 元のブランチで最新化する
ローカルのブランチを、Fetch 元のブランチの内容にアップデートします。
以下は、 development というローカルのブランチに移動し、Fetch 元の development でブランチで更新する方法です。
以下で、ローカルの development ブランチに作業ブランチを変更
git checkout development
Fetch 元 (true_origin) の development ブランチから PULL します。
git pull true_origin development
4. 最新になったローカルの development ブランチの内容を リモートの origin の development にも反映しておく
ローカル PC 上の最新コードを使って、今度は GitHub 上の fork した Repository を更新します。
いずれしても、この後いろいろ作業を行い、ローカルの development ブランチを 更新した時に、commit して push するのでここでやらなくても良いです。
git push origin development
この作業は、origin の development ブランチを、ローカルの development ブランチの新しいファイルで全て上書きします。
その他の TIPS
自分の「PULL リクエスト」の "Notifications" は、ブラウザ上のボタンで「Subscribe」しておくとよいです。
管理者からのコメントが来た時に、自分の GitHub アカウントのメールアドレスに通知メールが飛んでくるようになります。
