GitHub基礎 | マージまでの流れ・PullRequestまでの流れをおおまかに理解

Gitは使ったことがないので、現場で使っていそうな方の記事を参考にまとめてみました。

## はじめに
職場でもGitやGitHubを使っていないため、実際の商用環境ではどのような使われ方をしているか、プロはどのように使っているのか気になり、調査結果をまとめてみました。

## Gitでのマージまでの流れ

### マージの流れ
まずは、おおまかな理解にこちらです。大変わかりやすかったです。

[A successful Git branching model を翻訳しました](http://keijinsonyaban.blogspot.jp/2010/10/a-successful-git-branching-model.html)

そのほかどんなやり方が現場で行われているか、調べます。

#### ブランチの種類
上記サイトで紹介のあるブランチの種類を先に理解します。

参考：
![001_git (1).jpg](https://qiita-image-store.s3.amazonaws.com/0/176316/d80619e0-6d91-0dd4-cf2e-c206d1e1c428.jpeg)

※#1はこのあとの説明にリンクしているだけです。

1) メインブランチ
- 名前：masterやdevelop

2) リリースブランチ
- 名前：release-*
- 分岐元： develop / マージ先： develop と master
- サポートブランチと言われてます

3) ホットフィックスブランチ 
- 名前：hotfix-*
- 分岐元： master / マージ先： develop と master
- サポートブランチと言われてます

4) フィーチャーブランチ
- 名前は上記以外
- 分岐元： develop / マージ先： develop
- サポートブランチと言われてます


言葉でしっくりこないので、先に図示。


![001_git (4).jpg](https://qiita-image-store.s3.amazonaws.com/0/176316/c04644da-4c64-3c26-566f-dd225fb289e7.jpeg)


最初のフローのmasterやdevelopもローカルレポジトリのものと、一旦考えちゃいます。

origin/masterとローカルレポジトリのmasterは同じ内容を指していますが、異なるmasterです。origin/masterが更新されても、ローカルレポジトリのmasterは更新されないケースもあるので、そこは注意点です。


### プロはどのように管理しているのか

ということで、こちらを参照にさせていただきました。現場での使い方はなかなか難しい…

[Git のマージについて、自分的まとめ](http://tanaka51.hateblo.jp/entry/20120530/1338386845)より
> Git の世界では、「コミットの歴史を綺麗に保つ」事が非常に重視されています。

### 腑に落ちた点

参考URLより腑に落ちた点についてまとめます。

1. ブランチ作成時には分岐元、マージ先に気を付ける。
  - でないと、各ブランチでの更新分が正しい歴史として反映されない。
2. マージタイミングは各ブランチで管理（上の図が良い例です。）
3. コミットの歴史大事に。
  - 他チームもさわる`origin/XXX`の歴史は常に誰かが更新していることを意識。
  - 他チームもさわる`origin/XXX`のローカルに作った`リモート用ブランチ`*はローカル内では格上扱い。
  - それ以外は格下ブランチ。作業上、コミットが多いが整理はできていない。だから、その歴史はあまり人に見せたくない。
4. `git tag`コマンドでバージョン管理

\* 先の図でorigin/XXXをリモート追跡ブランチ越しで参照しているブランチ(masterなど)が"origin/XXXのローカルに作ったリモート用ブランチ"ですかね。確かに他の人もさわるので格上扱いです。

図示（+コマンド）：
使うコマンドを図に追記しました。

![001_git (5).jpg](https://qiita-image-store.s3.amazonaws.com/0/176316/0f8eb9af-cd6d-89ce-dd7e-65590af89ffa.jpeg)


### コマンド

|#|何する|From|To|書き方|意味|
|:--|:--|:--|:--|:--|:--|
|1|マージ|サポートブランチ（格上）|master(格上)|git merge --no-ff|格上同士は、お互い歴史が大事にされているので、マージコミットを敢えて残して、ブランチ統合。|
|2|マージ|格下ブランチ|リモート用ブランチ(格上)|git merge --squash|格下ブランチのコミット履歴は見せたくないので、--squashでひとまとめにして見せないで統合。|
|3|origin/XXXに変更があったので取り込む|origin/XXX(神)|リモート用ブランチ|git pull --rebase|リモート先でみんなが大事にしてきた歴史があるので大事に保つ、と。|
|4|origin/XXXに変更があったので取り込んでほしい|リモート用ブランチ(格上)|格下ブランチ|git rebase|歴史大事に取っておいて！という感じですかね。|




### その他参照
[3.5 Git のブランチ機能 - リモートブランチ](https://git-scm.com/book/ja/v1/Git-%E3%81%AE%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81%E6%A9%9F%E8%83%BD-%E3%83%AA%E3%83%A2%E3%83%BC%E3%83%88%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81)
[Gitの使い方備忘録 (git merge --squash)](http://qiita.com/kentahama/items/6988143254b673de656d)
[ブランチの統合](https://www.backlog.jp/git-guide/stepup/stepup1_4.html)
[トピックブランチと統合ブランチでの運用例](https://www.backlog.jp/git-guide/stepup/stepup1_5.html)

## GitHubでのPullRequestまでの流れ

### 皆様はどのように管理しているのか

- [ForkからPull Requestまでの大まかな流れ](http://numb86-tech.hatenablog.com/entry/2017/02/25/143908)
- [Github Fork Pull Request](http://kik.xii.jp/archives/179)


図示：
![001_git (2).jpg](https://qiita-image-store.s3.amazonaws.com/0/176316/53fc1dae-8f51-f76f-f6a0-85bfceade291.jpeg)

### 流れ

####Step 1. 環境準備（青色）
\#1 Forkする
\#2 git clone Forkしてきたリポジトリのパス


####Step 2. 作業：topic-branchでの作業と更新完了（桃色）
\#3 git checkout -b topic-branch　
ブランチ切り替え

\#4 作業とコミットを繰り返す
\#5 git push origin topic-branch
自分のGitHubをアップデート

####Step 3. PRに向けて：全masterの最新情報の同期（緑色）
\#6 git remote add upstream Fork元のリポジトリのパス
\#7 git checkout master  
masterで作業
\#8 git pull upstream master  
Fork元の最新の変更をローカルに反映・同期
\#9 git push origin master  
自分のGitHubのFork元のmasterに反映・同期

####Step 4. PRに向けて：topic-branchをoriginとローカルmasterへ反映（紫色）
\#10 git checkout topic-branch
\#11 git rebase master　
\#12 git push -f origin topic-branch

####Step 5. PR（記載なし）
\#13 Pull Request　
ここはGitHubのサイトから実施。PRをするブランチを選択する。自分が作業をしていたトピックブランチを指定。masterを指定しないよ！（masterも同期していたらそれでもOK。）

\#14 Merge
Fork元の人が決める。

####Step 6. PR Merge後の更新を反映（記載なし）
\#15 Step 3.をもう一度。PR Merge後の更新をtopic-branchへ反映すると。

####Step 7. topic-branch削除（記載なし）
\#16 git branch -d topic-branch
\#17 git push origin :topic-branch


*#13は自分用のGitHubから実施。PRの中で、リポジトリやブランチを選択する。#15で修正を求められた場合は、git push origin topic-branchでpushをもう一度行う。

>そうすれば、PRの内容も自動的に変更される。

## あとがき

gitコマンドはどんどん使って慣れるしかない。
あとマークダウンのセンスがなくて、きれいに書けないのも残念。