Git
GitHub
初心者

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

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

はじめに

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

Gitでのマージまでの流れ

マージの流れ

まずは、おおまかな理解にこちらです。大変わかりやすかったです。

A successful Git branching model を翻訳しました

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

ブランチの種類

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

参考:
001_git (1).jpg

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

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

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

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

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

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

001_git (4).jpg

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

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

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

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

Git のマージについて、自分的まとめより

Git の世界では、「コミットの歴史を綺麗に保つ」事が非常に重視されています。

腑に落ちた点

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

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

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

図示(+コマンド):
使うコマンドを図に追記しました。

001_git (5).jpg

コマンド

# 何する 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 のブランチ機能 - リモートブランチ
Gitの使い方備忘録 (git merge --squash)
ブランチの統合
トピックブランチと統合ブランチでの運用例

GitHubでのPullRequestまでの流れ

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

図示:
001_git (2).jpg

流れ

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