Git / GitHub ツール・ソフトウェア

GitHub で他の人の Repository に参加する方法

2020年3月14日

1. ブラウザで自分の GitHub アカウント作ってログインする

ブラウザで自分の GitHub アカウントでログイン。

2. ブラウザで 自分の参加したい Repository に移動して Fork ボタンを押す

ブラウザで、自分の参加したい GitHub の Repository に移動して Fork ボタンを押す。

これだけで、自分の Repository の下に、他人の Repository が Fork される。

3. ブラウザで、自分のアカウントの下に Fork された Repository ができた事を確認する

ブラウザで、GitHub の 自分のアカウントの下に Fork された Repository ができた事を確認する。

Fork 元が apache/project1 であれば、myname/project1 ができる。(myname は自分の GitHub アカウント)

 

4. ローカルに、Fork した Repository を Clone する

 

git clone https://github.com/myname/project1

git clone を実行した時に、ローカルブランチが一つ作られる。

clone 後、何も考えずにファイルの編集をはじめた場合でも、実はそのデフォルトのブランチの中で作業している事になる。

Clone 元の Repository が、何と言う名前のブランチをデフォルトとして使っているかは、 git branch で確認できる。

一番多いのは、GitHub で Repository を作った時にデフォルトで作られる master である。但し複数のブランチを持っている場合は、デフォルトを変更する事ができる 。

(git の使い方のハードルが高いのは、特に引数を指定しない時に使われる”暗黙”の名前やコンセプトが所々に潜んでいてからかなと思う)

Repository は、多くのケースで複数のブランチを持っているが、git clone した時にローカルに作られるのは、その Repository のデフォルトのブランチだけである。

 

5. ローカルに、作業用のブランチを作る
git branch <ローカルブランチ名>

Push しない限り、これはローカルにだけ、存在するブランチになる。

以下を行うと fork した Repository のデフォルトのブランチ から mylocalbranch という名前のローカルブランチが作られる。

「forkした Repository のデフォルトのブランチ」は、「fork 元の Repository のデフォルトのブランチ」がそのまま反映されて引き継がれるが、デフォルトでは master という名前が使われる。後から変更する事も可能であるが、Repository 作成者が特に変更していない場合は master が使われる。

git  branch  mylocalbranch

ブランチ名には、"/" も使える。なので issue 番号 1234 に対しての fix で test.json を修正するという意味で「fix/#1234/test-json」というブランチ名も作れる。

このブランチは、後で PULL リクエストが Fork 元にマージされた後は、消すので管理しやすい名前にする。

もしデフォルト以外の特定のブランチから新しいローカルのブランチを作る場合は以下のようにする

git checkout -b <新しいローカルのブランチ名>  origin/<派生元のブランチ名>

checkout は、<派生元のブランチ> の内容をコピー (checkout) して、<新しいローカルのブランチ> を作るイメージになる。

ここで、origin って何だろう?となるが、origin は、「リモート」の名前で、「リモート」はクラウド上にあるリポジトリーの事を指す。
クラウド上のリポジトリから、git clone で、ローカルのリポジトリを作成した時に、クラウド上のリポジトリに origin という名前が自動で付けられる。

また、ローカル・ブランチを新しく作った事で、複数のローカル・ブランチを持つ事になる。
自分が現在どこのローカル・ブランチにいるかは以下の方法で確認できる。

git branch
6. 修正を作成する

ここでは、test.json というファイルを修正した事にする。

7. 修正を作業用ブランチにコミットする

「コミット」は、ローカルの Repository に対して変更を確定する作業になる。

編集した「test.json」を、ローカルの Repository に対して、確定した変更として「コミット」する。変更確定を登録するような作業になる。

git add test.json
git commit -m "small changes"

git add <ファイル名> は、<ファイル名> を、コミット予定のリストに追加する事を指す。

一個一個、手作業で直接コミットしても良いが、コミット予定ファイルのリストを作って置いて、後でそのリストに載っているファイルを丸毎コミットできるようにするため、ワンクッションを設けているようだ。

git commit -m "small changes"  の -m の部分は、後で Fork 元に PULL リクエストをした時に、以下のように PULL リクエストの下に小さく表示される。みんなが見る所なので、あまり適当な事を書くと恥ずかしい事になるので注意する。

以下は、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 は、ローカルで作られたものなので、originmylocalbranch というブランチが新しく作られる事になる。

新しいブランチが  origin  にできるだけなので、 origin の Repository のどこかを破壊するという事にはならない。

もし origin の既存のブランチを指定した場合は、 origin のブランチはアップデートされる事になる。

なお、fork 元 (この例では true_orign はアップデートされないし、そもそも権限が無いので fork 元は普通にはアップデートできず、PULLリクエストを送って変更をマージしてもらうようにお願いする必用がある。

9. ブラウザで GitHub の自分のリポジトリに行くと、Fork 元の Repository に、PULL リクエストが送れるようになっている。

Fork 元の Repository 名とブランチを指定し、そこに対して PULL リクエストを送る。

「PULL リクエスト」と言った時に、

  • 「自分のローカル Repository をリモートの Repository で上書きする場合」と、
  • 「他人の リモート Repository に、自分のリモート Repository の内容のマージを依頼する場合」

の2つがある。「PULL リクエストを送る」は後者の場合の文脈のみで使われる。

「PULL」で上書きされるのが、他人のリモート Repository なのか、自分のローカル Repository なのかの違いになり、視点が違う。

相手への上書きを依頼する PULL リクエストは、リモートの Repository 間で行える作業で、「ローカル」Repository から「リモート」Repository に直接 PULL リクエストはできない。

これは、ローカルからのリクエストだと PULL リクエストの内容がハッキリしない事に関係していると思われる。 userid / password は、送れるので、その userid / password を使って GitHub で認証してもらえば身許確認はできると思うが、そもそもネット上の Repository からの PULL リクエストで無いと、PULL リクエストされているコードの内容がわからないためだと思われる。

事前にブランチ間の差分はチェックされ、差分が何もないと、以下のようにPULL リクエストが送れない(There isn't anything to compare)

 

Fork元との同期

Fork 元のブランチ(リポジトリ)がアップデートされても、Fork したブランチ(リポジトリ)にはアップデートされないので以下の作業をする必用がある。

前提:Fetch 元に development というブランチがあり、ローカルにも development というブランチがある。これを Fetch 元の最新でアップデートする。

1.  Fork 元の Repository を、リモートとして追加する

Fork 元になった Repository を、「リモート」として追加する。

「リモート」は、はじめは  origin というものが定義されているはずだが、それはクラウド上の自分のアカウントの下の fork された Repository を指す。fork されたプロジェクトをローカルに clone した時に clone 元 (つまり fork された Repository) を指す名前として origin が自動で作られている。

origin という名前に https://github.com/myname/project1 というような GitHub 上の URL が結びついているとイメージになる。

また origin という名前は、URL に紐付くもので、自分のローカル Repository がそう呼んでいるだけで、他の人は test と名付けている可能性もある。 origin という名前は誰から見ても同じグローバルな名前では無く、デフォルトで origin という名前が使われるが、それぞれのユーザー (ローカル Repository) が origin に結びつけている リモート Repository の URL は通常別物である。

ここでは、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 はできるが、ローカルに true_origin の全てのブランチを fetch (ダウンロード) して置く事で、タブキーで、true_origin  <branch 名> のような時に <branch 名> を補完してくれるようになる。

※ fetch  は merge までは行わないので、既存のローカルブランチに影響は出ない

git fetch true_origin

これで、git branch -a を実行した時に  remotes/origin/<ブランチ名>  に加えて  remotes/true_origin/<ブランチ名> も出てくるようになっているはず。

3.  ローカルのブランチを、Fetch 元のブランチで最新化する

最新化したいローカルのブランチに変更。

以下は、 development というローカルのブランチに変更。これを Fetch 元の development でブランチで更新する

以下で、ローカルの development ブランチに変更

git checkout development

Fetch 元 (true_origin) の development ブランチから PULL する。

git pull true_origin development
4. 最新になったローカルの development ブランチの内容を リモートの origindevelopment にも反映しておく

後でローカルの development ブランチを 更新した時に、commit して push するのでここでやらなくても良い

git push origin development

これは、origin の development を、ローカルの development の新しいファイルで全て上書きする

 

その他の TIPS

自分の「PULL リクエスト」は、ブラウザ上のボタンで「Subscribe」しておく。

管理者からのコメントが来た時に、自分の GitHub アカウントのメールアドレスに通知メールが飛んでくる。

created by Rinker
¥2,208 (2020/04/05 05:45:15時点 Amazon調べ-詳細)

タグ

-Git / GitHub, ツール・ソフトウェア

Copyright© エンジニアの何でもメモ帳 , 2020 All Rights Reserved.