Gitは使ったことがないので、現場で使っていそうな方の記事を参考にまとめてみました。
はじめに
職場でもGitやGitHubを使っていないため、実際の商用環境ではどのような使われ方をしているか、プロはどのように使っているのか気になり、調査結果をまとめてみました。
Gitでのマージまでの流れ
マージの流れ
まずは、おおまかな理解にこちらです。大変わかりやすかったです。
A successful Git branching model を翻訳しました
そのほかどんなやり方が現場で行われているか、調べます。
ブランチの種類
上記サイトで紹介のあるブランチの種類を先に理解します。
参考：
※#1はこのあとの説明にリンクしているだけです。
1) メインブランチ
- 名前：masterやdevelop
2) リリースブランチ
- 名前：release-*
- 分岐元： develop / マージ先： develop と master
- サポートブランチと言われてます
3) ホットフィックスブランチ
- 名前：hotfix-*
- 分岐元： master / マージ先： develop と master
- サポートブランチと言われてます
4) フィーチャーブランチ
- 名前は上記以外
- 分岐元： develop / マージ先： develop
- サポートブランチと言われてます
言葉でしっくりこないので、先に図示。
最初のフローのmasterやdevelopもローカルレポジトリのものと、一旦考えちゃいます。
origin/masterとローカルレポジトリのmasterは同じ内容を指していますが、異なるmasterです。origin/masterが更新されても、ローカルレポジトリのmasterは更新されないケースもあるので、そこは注意点です。
プロはどのように管理しているのか
ということで、こちらを参照にさせていただきました。現場での使い方はなかなか難しい…
Git の世界では、「コミットの歴史を綺麗に保つ」事が非常に重視されています。
腑に落ちた点
参考URLより腑に落ちた点についてまとめます。
- ブランチ作成時には分岐元、マージ先に気を付ける。
- でないと、各ブランチでの更新分が正しい歴史として反映されない。
- マージタイミングは各ブランチで管理（上の図が良い例です。）
- コミットの歴史大事に。
- 他チームもさわる
origin/XXXの歴史は常に誰かが更新していることを意識。 - 他チームもさわる
origin/XXXのローカルに作ったリモート用ブランチ*はローカル内では格上扱い。 - それ以外は格下ブランチ。作業上、コミットが多いが整理はできていない。だから、その歴史はあまり人に見せたくない。
- 他チームもさわる
-
git tagコマンドでバージョン管理
* 先の図でorigin/XXXをリモート追跡ブランチ越しで参照しているブランチ(masterなど)が"origin/XXXのローカルに作ったリモート用ブランチ"ですかね。確かに他の人もさわるので格上扱いです。
図示（+コマンド）：
使うコマンドを図に追記しました。
コマンド
| # | 何する | 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までの流れ
皆様はどのように管理しているのか
図示：
流れ
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コマンドはどんどん使って慣れるしかない。
あとマークダウンのセンスがなくて、きれいに書けないのも残念。