Git(プルリク作る、レビュー受ける、マージする)

[sumakokima2]

手順

1. 最初にプロジェクトをスタートする 1.1. git clone

$ git clone %gitのパス% これは、既存のプロジェクトを最初にローカルパソコンにダウンロードするときに使います。 ターミナルで、gitで作業したいディレクトリに移動してからこれを入力すると、自動的にgitのファイル名と同じディレクトリとその中身が作成されます。

1.2. npm install

通常、cloneしたディレクトリにpackcage.jsonも内包されています。packcage.json内に、プロジェクトで使用するモジュールが全て書かれています。cloneをしたらターミナルで、cd ***を入力してそのディレクトリに移動し、npm installを行います。 すると、開発に必要なモジュールが全てインストールされます。

3/31追記 作業するプロジェクトに、yarn.lockが含まれていた場合、npm installの代わりにyarn installでもモジュールのインストールが可能です。

2. gitで開発を進める 　2.1. branch gitで作業するときは必ずbranchを設定します。 branchは、開発の基盤となるmaster branchを汚さないように、更新の状態を別に保存しておく場所です。branchの状態は git branch -a で確認できます。

　2.2. branchの作成と切り替え 自分で作業を進めるbranch を作成します。 $ git branch %ブランチ名% ここで、 git branch -a を入力すると、現在存在するブランチを全て確認することができます。現在自分がいるbranchが緑色で書かれ、" * "がついています。 注意すべき点は、branchを作成したら、自動的にそのbranchに移動することは無いということです。なので、branchを作成したら必ずcheckoutして作業を進めるbranchを移動する必要があります。 $ git checkout %ブランチ名%

3. ソースコードの書き換え(add, commit, push) gitでソースコードを書き換えたら、add, commit, push　の段階を経て、リモートgitにデータが反映されます。

git add は、作業ツリーにあるファイルの更新内容を、インデックスに反映するための Git コマンドです。(http://www-creators.com/archives/4939)

git commitとは一言で言うと「追加・変更したファイルをGitに登録するためのコマンド」です。(https://www.sejuku.net/blog/71279)

これらは各々その機能を説明されることが多いですが、私は別々に言われても理解できませんでした。なので、add(完全ローカル)-commmit(まだローカルだけど、pushしたらリモートに反映される)をローカルゾーンとしてひとまとまりとして扱い、そのあとpushする(リモート)という風に分けてここに記述します。

3.1 addとcommit addは自分の中でローカルgit状に変更データを保管するために使用します。 commitは、addされたデータを「コメント付き」でgitに登録するためのものです。 ここで、注意したい点は、commitで書かれた「コメント」は「残る」ということです。 commitの説明の時に、「コメント」と書かれることが一般的ですが、「コメント」というよりは「変更報告」です。他の人が変更内容を一目でわかるように書く必要があります。

コミットメッセージは、どんな実装をしたかを、簡潔に記述してください。自分用の作業メモはコミットメッセージに書かないでイシューに書いたほうが良いかと思います。。。

「○○○を実装」「Implement xxx」 「○○○を修正」「Fix xxx」

また、変更したファイルを一括でaddしてcommitするよりも、ファイルごと、変更箇所ごとに都度addとcommitした方が、その後の管理がスムーズになります。

私の場合、（いまだにaddのタイミングを掴めてないのですが）、なんとなく、関数を一つ作成したらadd- commitするようにしています。なお、addとcommitは取り消し可能です。

以下に一連の流れを書きます。 ソースコードを書き換えたらまずadd します。

$ git add %編集したファイル%

※間違ってaddした場合 $ git reset HEAD %編集したファイル%

コミットする $ git commit -m "コメント"

3.2 push

Gitには「ローカルリポジトリ」と「リモートリポジトリ」という2つのリポジトリがあります。 リモートリポジトリに変更を反映するのが「Push」です。(https://teratail.com/questions/79531)

要は、pushしてしまうとリモートに行ってしまうため共同開発者全員から見られてしまいます。 pushの取り消しもできるようですが、なんらかの混乱を招く恐れがあるらしいので、そのときはこっそり削除するよりも、共同開発者に相談した方がいいかと思います。

$ git push origin %ブランチ名%

4. プルリクを作る

前置きが長くなりましたが、ここからが本題です。 master branchに変更データを反映させてもらうための要求（リクエスト）をします。 プルリクエストは、ブラウザ状でできます。

ブラウザのgitで、tabにある「Pull request」から、「new Pull request」をクリックします。 ここで、「ブランチ名（プルダウン）」　←　「ブランチ名（プルダウン）」から、右側を自分の開発ブランチにセットします。

ここで、プルリクエストの名前を書く点での注意点です。

プルリクエストの名前は、どんなことをするのかを書いてください。例えば「CZMLの変換処理を実装」 それがマージしたときのコミットメッセージに入ります。

5. レビューを受ける

プルリクエストをしたら、他の人から変更箇所のチェックをしてもらいます。 これを「レビューを受ける」と言います。 レビューを受けたい場合は、プルリクエストのページの右側タブにあるreview部分から、レビューしてほしいユーザをクリックします。 こうすると、そのユーザにレビューの依頼が届き、内容をチェックしてもらうことができます。

初心者の場合、このレビューで様々な課題が浮き彫りになります。 pull requestページ内のコメント数が膨大になります。。。

レビューを受けて、自分で書き直して、add, commit, pushした場合、_再びレビューの依頼をする必要があります。_上記のレビューのリクエストと同じ手順で、再度レビューの依頼をすることができます。

6. マージする

マージのためには、「レビューを受けてから」、「プルリク作成者が自由にできる」、「マージする人に制限がある」などの条件があります。 私の場合、プルリクエストとレビュー依頼までが私のできる範囲で、マージについてはボスの権限でした。

3/31追記 再レビュー依頼という概念は特にGitHubにはないようです。変更をプッシュしたら、単にPRのコメントやSlackで「もう一度レビューお願いします」って声かけるだけでも大丈夫と思います。

5. 自分の作業中にmasterブランチが進んでいた場合 masterの変更をmasterから自分のブランチに取り込んで（競合が発生した場合は自分で解消して）から、レビューを依頼します。（でないとmasterに自分のブランチをマージできません）。

例えば、自分のfirst-branchがマージされた直後に、再度最新情報を取り込みたい場合は、

git pull origin master　（これは、git fetch + git merge） git pull --rebase origin master

で最新情報に更新できます。

fetchとpullの違いは、 「取得したブランチ情報をローカルブランチにマージするかどうか」にあります。 fetchのみでは、最新情報を見ることはできるものの、ユーザ自身が自分のブランチの内容に 反映させることはできません。反映させるためには、mergeが必要になります。このfetch+mergeをまとめてやってくれるのがpullです。

git branchについて gitのブランチで私が混乱した点についてここに書きます。 git branch -aを叩くと、branchの一覧が表示されます。 ここで、注意したいのは、「remotes/origin/...」はリモートの「追跡」ブランチです。あくまでローカルにあるけれども、リモートとしての立場を保守しているので、書き換えなどはできません。

なお、「remotes/origin/...」が書かれていないbranchが純ローカルブランチになります。

master test remotes/origin/HEAD -> origin/master remotes/origin/batch remotes/origin/feature/makeicon remotes/origin/master remotes/origin/test remotes/origin/test1 remotes/origin/twitter-sena

つまり上記branchの構造から、fetch+mergeの場合は、自分のローカルのリモート追跡ブランチにデータを持ってくるわけで、自分の作業しているbranchに反映させたい場合は、git merge origin/masterをたたく必要があるわけです。

「fetchのみでは、ローカルリポジトリの中にはmasterとorigin/masterの２つそれぞれの情報が置かれていることになります。 fetchを行ったときに新しい更新があったとするとorigin/masterが最新になり、masterはその分の更新がまだ行われていない事になります。」(https://qiita.com/osamu1203/items/cb94ef9da02e1ec3e921)

pullではなく、fetchをするべきという意見には、「内容を確認したのちに、マージ作業に取りかかるべき」「内容の衝突を防ぐ」と言った視点があるようです。

さて、ここで --rebaseをつけるかつけないか　です。http://kray.jp/blog/git-pull-rebase/

git pull origin master (fetch + merge)または git pull --rebase origin master

-rebase オプションをつけてプルすると、履歴にマージコミットが作られないため、記録が綺麗になります。

色々説はありますが、git pull --rebase origin masterが推奨されているようです。 --rebaseをつける点について、原田は、「複数人によって枝分かれした複雑なツリーに対し、自分の部分（ブランチ）をちょん切って、メインの先っぽに付け足す」作業として解釈しました。最終的に、管理者がツリー情報を「視覚的」に把握しやすくなるために行う作業として捉えています。

masterの変更をmasterから自分のブランチに取り込んでからpullする理由は以下です。

checkoutした直後は下記の状態になる。

develop        o-o-o
              /
master o-o-o-o

これがしばらく進むとmasterでの開発が進んで下記の状態になる。

develop        o-o-o
              /
master o-o-o-o-o-o

このままpushするとconflictが起きやすい。そこで下記のようにしたい。

develop             o-o-o
                   /
master  o-o-o-o-o-o

この時使うといいのがgit pull --rebaseなのだ。(https://qiita.com/makua/items/7aa1f4fa02ef9ab1f9d9)

[rot1024]

npm install について

もしyarnを使っているプロジェクト（yarn.lock ファイルがあるかどうかで判断可能）の場合は、npm install の代わりに yarn です。

[rot1024]

レビューを受けて、自分で書き直して、add, commit, pushした場合、_再びレビューの依頼をする必要があります。上記のレビューのリクエストと同じ手順で、再度レビューの依頼をすることができます。

再レビュー依頼という概念は特にGitHubにはないようです。変更をプッシュしたら、単にPRのコメントやSlackで「もう一度レビューお願いします」って声かけるだけでも大丈夫と思います。

[rot1024]

自分の作業中にmasterブランチが進んでいた場合の方法も、是非書いてください。

masterの変更をmasterから自分のブランチに取り込んで（競合が発生した場合は自分で解消して）から、レビューを依頼します。（でないとmasterに自分のブランチをマージできません）

http://kray.jp/blog/git-pull-rebase/

こちらもご参考までに。

[sumakokima2]

更新しました！段落が見にくいので、要改善です。