- 日時: 2017/06/27 15:00~16:30
- 場所: 301教室
BookChain(仮称)プロジェクトは、GitHub Flowのブランチモデルで開発を行う。 それにあたって、プルリクエストのやり方をなんとなく説明することになった。 ついでに、Twitter班のメンバーも参加することになった。
https://github.com/kbc-itw/journal
部のorganization(kbc-itw)に所属している上記リポジトリを、個人のアカウントでフォークしてみる。 リポジトリのwebページの右上のほうに Fork というボタンがあるので、ぽちっと押せばOK。
もともとのリポジトリと同じ情報を持ったリポジトリが、自分のアカウントの下に作られる。
オリジナルの方ではなく、フォーク先をクローンしてくること。
git clone https://github.com/${自分のアカウント名}/journal.git
ブランチの名前は、変更内容を端的に表すものにしよう。 Topic(=話題)ブランチとも言うが、「どのファイルを変更」というのではなく、 「何のために変更」「どういう機能を実現」というような要点を名前にするように心がけよう。
# クローンしたリポジトリに移動
cd journal
# 新しいブランチを作って、チェックアウト
git checkout -b READMEに${自分の名前}を追加
# READMEに何かしらの変更を加える
vi README.md
# いつものコミット操作
git add .
git commit -m "READMEに${自分の名前}を追記した。"
ローカルに保持している変更を、リモートにアップロードする。 (この辺の操作はCUIだとオプションとか若干面倒。)
git push --set-upstream origin READMEに${自分の名前}を追加
現在登録されている origin というリモートリポジトリは、フォークした先の、自分の名義の下にある方のリポジトリであることに注意。 該当リポジトリのwebページを開いて、ちゃんとブランチが上がっているか確認してみよう。
これはwebでの操作になる。 自分の方のjournalリポジトリのwebページを開いて、 画面の上の方にある Pull Requests タブを選択しよう。
すると、画面右上の方に New pull request というボタンがあるので押す。
プルリクエスト作成画面が表示される。
base fork は、変更を取り込んでほしい先のブランチを指定する。
head fork は、取り込んでほしい変更を加えたTopicブランチを指定する。
今回の場合は、base forkが kbc-itw/journalのmaster、
head forkが${自分のアカウント名}/journalの${Topicブランチ名}
という風になる。
選択が完了すると、画面下部にそのプルリクエストによる変更の一覧が表示されるので、確認しよう。
確認ができたら、 Create pull request ボタンを押す。
元リポジトリ(kbc-itw/journal)のwebページを確認すると、 自分が作成したプルリクエストが登録されているはず。 あとは、管理者のレビューを待つしかない。
やったね!
プルリクエストの変更内容が管理者のお気に召さなかった場合、 再度変更を求められることがある。
指摘された変更をローカルで行って、プルリクエストに利用したTopicブランチ上でコミットしたのち、 再度自分のリモートリポジトリにプッシュする。 そうすると、自動的にプルリクエストに変更内容が反映される。 プルリクエストを作り直したりする必要はないぞ。
vi README.md
git add .
git commit -m "自分の名前を間違えていた問題を修正"
git push origin ${トピックブランチ名}
そもそもそのプルリクエスト自体が根本的にいらなかったりする場合は端的に拒否される。 あきらめるなりなんなりしよう。
プルリクエストが取り込まれると、オリジナルのリポジトリに変更が発生する。 しかし、それが自動的にフォーク先のリポジトリ(自分のアカウントにあるやつ)に反映されたりはしない。
あくまでも、 これら2つのリポジトリは別々のリモートである からだ。
変更を反映させてやりたかったら、以下のような作業を行う必要がある。
# オリジナルのリポジトリを、upstreamという名前でリモートとして追加
git remote add upstream https://github.com/kbc-itw/journal.git
# オリジナルのリポジトリの内容をローカルに落としてくる
git fetch upstream
# (masterの状態をオリジナルリポジトリに合わせたい場合)
# masterにチェックアウトする
git checkout master
# 元リポジトリのmasterの状態を、ローカルのmasterにマージすることによって取り込む
git marge upstream/master
# フォーク先リポジトリであるmasterに変更をアップロード
git push origin master