なぜいまさらPull Requestの練習か
今まで機能があるのは知ってたけど、個人のソースコード管理程度にしか
Githubを利用していなかったんですが、社内で利用されているっぽい話を聴いたので、
対応できるようにちょっとだけ使えるようにしておこうと思い書きました。
※こちらのページはForkしてからのPull Requestではなく
ひとつのリポジトリを複数の開発者でプルリクエストを
送り合いながら開発を進めていくためのものです。
リポジトリにpushできる権限が必要になります。
Github flow
過去のブログ記事を読んでね
link
ざっくり手順
- リポジトリを作る(既存のリポジトリにコミットする場合は省略)
- ローカルにcloneする
- $ git clone [repository path]
- 開発用にブランチを作成する
- $ git checkout -b [branch name]
- ソースコードを編集する、開発を進める
- コミットする
- $ git add [filepath]
- git commit -m ‘comment’
- githubの対象リポジトリにpushする
- masterにpushしちゃ絶対ダメですよ
- $ git push origin [branch name]
- githubをブラウザで開き対処リポジトリのページに移動する
- ブランチが作成され、先程の変更がpushされていることを確認する
- pushした内容が問題なければpull requestを送る
ここまでがソースコードを編集して、コミットして、リポジトリ管理者に
pull requestを送るまでの手順。
編集したソースコードに問題がなければ、管理者がpull requestを
承認して、(github flowなら)masterにマージされます。
以下より、pull requestを承認してマージするまで
手順。
- githubの対象リポジトリのページに、pull requestが届いていることを確認する
- 変更内容や、pull request送信者からのコメントなどが参照できるのでチェックする
- 自分の環境で動作確認してみる
- $git fetch;
- git branch -a;
- git checkout -b [branch name] [remote branch name]
- 問題なければ、githubのページのマージボタンを押す。(コメントも書けます)
- 必要がなければマージ済みのbranchをgithubから削除する
これでmasterブランチに、開発者が編集してくれたソースコードがマージされます。
補足
- 間違えてもmasterにpushしないこと。(権限は持ってるので注意)
- マージした後、ブランチをgithubのWEBページ上で削除すれば、Githubからはブランチが消えますが、もちろんローカル
環境には残っているので、適宜整理しましょう- $ git remote prune origin (これで削除済みのremoteブランチと同期とってくれる)
- $ git branch -d [branch name] (マージ済みのローカルブランチはこれで削除)
- コードレビューや動作チェック後はLGTM(Looks good to me)と呼ばれる
画像をコメントに貼ってあげるのがトレンドっぽい- (編集内容に対するFacebookのいいね!みたいなもん)
- githubのコメントへの画像の投稿はMarkdown形式で画像へのURLリンク貼るか、画像をドラッグアンドドロップでOK
- Github flowよくわからん、って人は一回上記の流れを一人でやってみると、ピンと来ると思います。