gitの運用を理解して使い分ける
はじめに
2 種類の git 運用でやらかし掛けた話を備忘録として記録します。
簡単に自己紹介
未経験からフロントエンドエンジニアにジョブチェンジして 1 年目です。
現在、2 つのプロジェクトを経験させていただいてます。
前提
1 つ目のプロジェクトでは、git の拡張機能であるgit-flowを取り入れたバージョン管理を行っています。
いろんな管理手法があると思いますが、今の現場では、下のような git-flow のGetting start通りの管理でブランチを切っています。
<!-- developからブランチを切る -->
git flow feature start hoge
上記のコマンドで、feature/hogeというブランチがローカルに生成されます。
<!-- 作業ブランチをマージする -->
git flow feature finish hoge
上記のコマンドを叩くことで、feature から develop にマージされ、ローカルブランチからfeature/hogeが、自動で削除されます。
また、コンフリフトが発生した場合、上記のfinishを実行した時にコンフリフトが発生します。
このタイミングで、コンフリクトを解消し、作業ブランチをマージさせたdevelop をそのままプッシュしています。
<!-- developをリモートにプッシュする -->
git push origin develop
このプロジェクトでは、プルリクエストがありません。
実際にやらかしそうになったこと
勘の良い方でしたら、すぐに気づきそうなことですが、Github とプルリクありきのプロジェクトで、develop に feature をマージしてプッシュしそうになりました。
自身で git の勉強をしているときや、研修時は、苦戦しながらもコンフリクト解消を Github・プルリクエスト 経由でやってはずなんですが、慣れとは怖いものです。
ですが、久しぶりに下の表記を前にして、 ん？git-flow の拡張機能を使わない場合、どうやってコンフリクト解消するんだっけ？ と、コンフリクト解消の方法がすぐに出てきませんでした。
全然忘れたが、develop に pull して、feature を develop にマージすれば良かろうと思い、コマンドをバコバコたたいていました。（安直、アホ過ぎる、、、）
でもずっと、 develop にマージしたら、プルリクで修正箇所があっても、すでにマージされてるやん、何のためのプルリクなんだろうなー? という疑問が頭にありました。
後学のために、ちょっと調べてみるかくらいのノリで、調べて出てきた下の記事を見て、肝を冷やしました。
コンフリクト時に、マージしないといけないブランチが、いつもやってるgit-flowと逆だったからです。
<!-- developにfeatureをマージするgit-flowの運用 -->
- git flow feature finish hoge
<!-- featureにdevelopをマージするプルリクありきの運用 -->
+ git merge develop
まとめ
- プルリクエストがある場合、feature に develop をマージする
なぜなら、作業ブランチを develop にマージするか、しないかの判断は、プルリクエストでレビュアーが判断するから。
技術書読んだり、テックブログ読んだりしてるけど、まだまだ全然知識が足りてないことを実感しました。
参考
Discussion