git学習メモ

教えてもらったこと、わからなくなったら見返すメモ

リポジトリ、ブランチについて

リポジトリにもブランチにも、それぞれリモート/ローカルがあることをわかってなくて最初かなり混乱した。
ここおさえたらかなりスッキリした気がするな。

●originがついてるついてないの違い
origin/master ←リモートブランチのこと。<リポジトリ名>/<ブランチ名>
master ←ローカルブランチのこと
originがついてればリモートブランチ、ついてなければローカルブランチなのね。

ちなみにリポジトリに対してはいちいちoriginとかつけなくて、リモートリポジトリ/ローカルリポジトリ という呼び方をする。

●わたしはいまどこにいるの？
自分がいつもローカル環境でcloneして作業してるのはどこかっていうと、
「ローカルリポジトリの先にある、ローカルブランチ内」なのね。
ローカルブランチ内のファイルに変更を加えて、
commitすると「ローカルブランチ→ローカルリポジトリに反映」されて、
pushすると「ローカルリポジトリ→リモートリポジトリに内包するリモートブランチに反映」されるという。

ここらへんフワッとしてたわ。
文章にするの難しいな。図のほうがわかりやすいかもな。

説明されるときって、わざわざリモートローカルの区別して話されることあんまりないから、しばらくは頭の中で「これはリモートブランチの話だから、origin/○○だな」みたいに意識して分けよう。
きっとすぐ慣れて、意識しなくてもわかるようになるよね。

-----

実際の運用例を聞いたからメモ

これはチームによってぜんぜん違うらしく、あくまで一例とのこと。

●前提
一番偉い人、中間管理職、担当者、のチーム開発とする。

●まずは、ブランチに役割をもたせよう
とりあえず3つあればOK。
・origin/master
本番環境用。origin/developからしかマージしない一番偉いブランチ。直接編集することはほとんどない。

・origin/develop
テスト環境用。↓担当者用の開発ブランチからマージを受け、テストがOKだったら↑origin/masterへプルリクを出す、板挟みなブランチ。直接編集することはほとんどない。

・origin/develop-案件番号
担当者が実際の開発につかうためorigin/developから切って持ってくる、下っぱブランチ。

●開発を始めるため、最初の準備をしよう
origin/masterをキックオフできる状態にして、origin/developを切る。
(origin/masterとorigin/developは同じ資材が入っている状態にする。)
これで、各担当者が開発をはじめる準備ができた。

●(プレーヤー：担当者)ローカル環境で開発を始めよう
origin/developをcloneしてローカルにもってくる。
(ローカルリポジトリが生成され、developが作成される)

さらに担当者が編集する用ブランチとして、developから、develop_案件番号ブランチを切る(ここではdevelop-001とする)。
好き勝手使っていいブランチができた！
develop-001はローカルリポジトリ内で作成したブランチなので、まだリモートリポジトリ内には存在しない。

●(プレーヤー：担当者)自分がした編集を、リモートリポジトリに反映させよう
develop-001に対して編集する。いいかんじに編集が終わったらファイルを
commit(ローカルブランチ→ローカルリポジトリへ反映する行為)、
push（ローカルリポジトリ→リモートリポジトリへ反映行為）する。
ここで初めてリモートリポジトリ内に、origin/develop-001が作成される。

●(プレーヤー：担当者)マージしてもらうため、プルリクを出そう
俺の編集おわったぞ！ってことで
origin/develop-001からorigin/developにプルリクを出す。

●(プレーヤー：中間管理職)レビューして受けたプルリクをマージしよう
origin/developはプルリクを受けて、内容をレビューする。
OKなら、origin/develop-001をorigin/developへマージする。
そんで、なんかテスト環境にデプロイとかする

---
ここからなんかテストとかするのかな。よく知らん。
とにかく、本番環境にデプロイしてよいかの検証をするの！
テストがOKだったら↓
---

●（プレーヤー：中間管理職）origin/developからorigin/masterへプルリクを出そう
一番偉いブランチに「テストOKだったから本番環境にデプロイさせてくれー！」って言うやつね。

●(プレーヤー：一番偉い人)レビューして受けたプルリクをマージしよう
origin/masterはプルリクを受けて、レビューする。
OKなら、origin/developをorigin/masterへマージする。
そんで、やっとこさ本番環境にデプロイとかする

おわり

レビュー体制についてメモ
origin/develop(テスト環境)のレビューは同僚、
origin/master(本番環境)のレビューは部長、
みたいな運用にすることもある
えらいひとはある程度きれいなコードしかみない的な。
間に挟まれる同僚のプレッシャーすごいな。笑

・origin/masterは基本的に、origin/developからしかマージしない運用
ザコブランチからのマージは受け付けないってことね！
運用でカバーするイメージかな。(設定でブロックできるかは知らん)

その他メモ
origin/develop-001をorigin/developへマージしたあとで（テストしてエラーとかでて）修正したくなったら、develop-001内ファイルを修正してプッシュすると、いきなりorigin/developにいっちゃう(origin/develop-001はマージ済のため)
その場合、origin/developでOKになったら、origin/masterへプルリクだす。
リモートでブランチまた分けてキャッチするみたいなことできるのかな？あとで調べるメモ
<追記修正>
「develop-001ブランチを消していないことが前提で、git pushで引数にdevelop-001を設定していればそこへマージされるので、同じブランチを使ってまたプルリクエストを出すことができます。」
とのこと！！ありがたや！！！！