ラジオネームめんぺきさんからのお便りですめんぺきさんおはようございます感想とかですソリッド原則の海沿いビュッフェ解説最高でした刺身膨張の例えが分かりやすかったです私はエンジニアではなく職場でパイソンスクリプトをたまに書く感じなのですがオブジェクト思考何もわからんパーソンから最近少しだけ脱出つつありソリッド原則やDDDへのビクツキを減らすためにタイムリーな話題だったのでとても助かりましたほう

これからも面白いポッドキャストを楽しみにしています皆さん健康にお気を付けて頑張ってくださいということでお便りいただいておりますありがとうございますポッドキャストで話してほしいことはGitの簡単な使い方Gitの簡単な使い方今日はGitの簡単な使い方のお話をするのは最初のちょっとだけで後半はブランチ戦略についてちょっと語っていきたいなと思います簡単な話ですね簡単

というので最初のGitの簡単な使い方からいきましょうかはい簡単な使い方これはどういうことだろうと思いながらも僕はとりあえずこれだけ覚えておけば大丈夫っていう切り口でちょろっと話しますまずGitこれは何かというとですね集団で一つのソースコードをいい感じに管理しようっていうやつです簡単に言うとねその通りはい

どういう風に管理するかというとですね基本的にはインターネット上じゃなくてクラウド上にマスターと言われるオリジナルコードがありますとそれをローカルの自分のPCにコピー持ってきて変更してリモートというかクラウド上に上げるみたいな形で使っていくのがギットのざっくりとした

考え方になってますなのでコマンドとか調べるとめちゃくちゃいっぱい出てくるんですよめっちゃ出てくるでめっちゃ出てくるんですけど僕その1,2年目はこの5コマンドで乗り切りました5まとまってるそんなイメージあるよ1つ目今もソースコードがあって作業するイメージで聞いてください自分が今開発してる1つ目Gitpull Rebaseオリジンマスター

オリジンメインかいきなりちょっと難しいやつ来た気がしますこれでプルができますプルというかソースコードを持ってきて自分のやつも更新できますっていうやつですで引っ張ってきてその後その後GitCheckout-Bで自分の作業ブランチを分けて

作業してGit addしてGit add.ですね全部更新してコミット-mでコミットメッセージを送りでプッシュするとなるほど大体それだよね最初のGit pullあれだよね

マスターから切って作業してたもののマスターが進んじゃったから取り入れたみたいな感じですね地元を更新するやつですね地元を更新ローカルを地元というえーそれ俺使ってなかったななるほど使わなくてもいいんですよ別に僕はこれで乗り切ったなっていうだけでなるほど今日のメインはGitのブランチ戦略ですおー

ブランチ戦略何かっていうとですねGitFlowって聞いたことありますかねはいGitFlowの話1回しましたね確か過去回ですねだいぶ前だよねだいぶ前にやったんですけど僕もGitのブランチ戦略ブランチどう管理していくかっていう方針を多分ブランチ戦略って呼ぶのかなGitFlowをよく使うんですねただ

世の中の人も結構そういう人いるかなと思うんですけどなんとなくGitFlow使ってるんじゃないということを投げかけたい他に何やるか知ってる?それってどうやってるか知ってる?ちなみにGitFlowをもう一回いいですか?どういうはいそれは後で言いますすいませんというので今日はですねGitFlow、GitHubFlow、GitLaboFlow3種類を紹介してで、あ、これいいねって最後にわかるみたいな

名前に過ぎやろそうですねはいちょっとお話させていただきます本日ですがGitKrakenっていうプロダクトのページの中にあったWhat is the best Git branch strategy?っていうどれが一番いいGitブランチ戦略なんやっていう記事からちょっと

紹介させていただきますGitKrakenGitKrakenはねGitのクライアントツールで一番かっこいいけどね機能が多すぎて俺は使い切れなかったツールの一つですねそうなんですねGUIね俺まだ使えてないんですけどねはいまず最初GitFlowからお話させていただきますちなみにGitFlowが一番複雑ですじゃあまずGitFlowからはい

まずGitFlowはですねGitのブランチデフォルトでマスターが作られるのかなでもメインなんですけどね最近はブランチを5種類に分けます5種類に分かれるというか5種類に分類されている1つ目がメインこれは本番本番で動いているやつ2つ目デベロップこれ開発するときに

更新するやつ公平があるかな開発中のやつか開発中というかステージングとかデブ環境で動いてるブランチみたいなそうですねステージング環境デブ環境で動いてるやつ3つ目フィーチャーこれは自分が作業してる時に使ってるやつ4つ目リリースリリースしたいやつこれは

複数バージョンGitFlowは管理できるのがメリットとしてあってですねライブラリじゃなくてライブラリとかだとねバージョン1系のやつとか1.2系のやつとかそういう複数バージョンを同時に一つのリポジトリで管理できるみたいな考え方でリリースブランチがありますリリース1.1.2みたいなでバックにあるリリース

最後Hotfixこれバグ出た時に直してる時に使うやつフィーチャーは正規的な正規の開発の時に使うやつでHotfixはバグ出た直さなきゃーって言った時に作るやつですねお急ぎ便だHotってそういうニュアンスですかメインデベロップフィーチャーリリースHotfixの5種類に分けて運用していくようなもので

なので主にメインとデベロップが普通の開発で使われてメインからデベロップが生えてデベロップからフィーチャーが生えるみたいな形でなんとなく開発は運用していくのかなという形ですメリットとチャレンジズという難しいところをブログでは紹介していてちょっと待ってください

もう少し具体的な話しますわブランチ今5つに分けるっていう話をしてましたけど開発の時はさっき言った通りメインからデベロップを分けてデベロップを変えていくとフィーチャーをそこから生やして開発終わったわって言ったらデベロップからメインに

合流させますとでよしじゃあ今回リリース1.0にしようってなったらそのメインからリリースブランチ切ってリリース1.0というブランチが生まれるとなるほどうわバグ見つかった大変だってなった時はですねメインとか各リリースブランチからホットフィックス生やしてホットフィックスをそのまま各リリースブランチメインブランチに

適応させるなるほどなんか大変そうですね職はもう小回り聞くわけだまあそうですね急ぎだからもう他のブランチとかやってらんねえそうですそうです現場の実情で言うとね開発中だしめっちゃ急ぐ必要もないからデベロップでもいいかみたいな時はあるっちゃうフィーチャーでやっちゃうこともあるっちゃう緊急じゃない時とかねまあそうね何ならバグチケットとか言ってバグのチケット貯め込まれてることとかあるよねありますね

死ななきゃ一生みたいなところもありますからねっていうのがGitFlowの流れですねこれはメリット3つあります1つ目が様々なタイプのブランチがあなたの仕事を簡単かつ直感的にしてくれるっていうところでさっき言った通りブランチごとに役割が明確なんですね確かに2つ目がシステマティックな開発プロセスがテストを効率的にさせるっていうので

さっき言った通り開発の流れがブランチの流れと合ってるというかなので例えばですけどリリースブランチを生やしたタイミングで自動で全テスト回すとかそういうことができるとフィーチャーがデベロップに入った時にデベロップ全部テストするとかそういうことができる2つ目

3つ目がリリースブランチの使用によって複数バージョンのプロダクションコードを簡単かつ継続的にサポートしてくれるというので僕がさっき言ったのと同じで複数バージョンを管理できるというのがこのGitFlowの良さの一つですね逆にGitFlowの難しいところというか微妙なところで言うとプロダクトの複雑性によっては複雑すぎますと

どういうことかというとですね複数のプロダクションコードを並行して管理することになっちゃうじゃないですかはいはいはい下手したらそうするとさっき言った通りホットフィックスでバグ修正しなきゃってなったら何個も提供しなきゃいけないとかああそっかそう確かにそう要はバージョン1.1から1.5まで0.1刻みだった時に前のやつから発見されたら全部に対してホットフィックス当てなきゃいけないそうですそうですそうですそうですそうですそうです

それは大変だ私はそう大変なんですよねあとですねCICDをするときってCICDっていうのは継続的インテグレーション継続的デリバリーっていうので主に大体デベロップとかにコードをプッシュしたタイミングでテスト回したりとかリリースブランチが更新されたタイミングで本番にデプロイするとかそういうのを自動化する考え方CICDって言いますけどえーと

いろんな開発者がフィーチャーからデベロップにプッシュしますとかやってるとプッシュしますもそうですしあとホットフィックスにいろんなリリースブランチに適用させますとかっていうとすんげいいろんなところでテストが同時に動いてめちゃめちゃ負荷かかるしクッソ大変ですこれってGitFlowってさっき言った通り長生きするブランチがいっぱいあるわけじゃないですかリリースブランチが特にそうですけどね

これがどうやらCICDの原則に反するらしいですそうなんだCICDの原則的にはそんなにたくさんの長期ブランチなんて持つなっていうそれはそうですよねあれもだってテストにお金かかったりしますし動作時間課金とかだったりしますよね確かそうですねなのでそういう長い開発サイクルを持っているものとかはしきっと微妙なんじゃないっていうところではありますうんうんうん

まあだからなんかわかりやすく言うとモンストとか違うんでしょうねきっとねモンスト久しぶりどういうことですかあれもだってねそのいろんなバージョンあるでしょうしねiPadiPhoneでiPhoneの中でも上のM字がないやつとかあるやつとか昔のiPhoneの画面でも対応できるとかなるほど

あれテスト多分大変なことになってるしリリースもめっちゃ頻繁なんで毎週クエスト毎週は言い過ぎか新キャラポンポン出たりとかなんとかとコラボ新ダンジョンできたとかあれアップデートじゃなくて開発スピードとんでもない確かに毎月だって

やってるもんね今月はこんなアップデートがありますみたいなニュースみたいなYouTube今もやってるんですかねどうなんだろうもっと軽いのでやってるんだろうなと想像してます実際わかりませんがそんなGitFlowが一つ目でしたここまでは慣れしだてに死んだやつかなと思うんですけど二つ目GitHubFlowですGitHubFlowこれは小さいチームやプロダクト向けのシンプルなワークフローで

どうなってるかというとですねこれはメインとフィーチャーしかありませんメインとフィーチャーのみシンプルそんなバカなメインコードにはプロダクションレディなコードが含まれますメインコードにはプロダクションレディなコードが含まれるメインブランチでしたどういうことでしょうかもうこれこのまま動かせるぜっていうぐらいのバグが入り込まないあとはフィーチャーがあるだけ

なるほどプロダクトレディな状態的な感じですかそうですそうですでGitHub Flowには守るべき6つの原則がありますここからのどういうブランチ戦略なのかちょっと読み取っていきましょうというところで一つ目はさっき言った通りメインブランチに含まれる全てのコードはデプロイ可能ですメインブランチに含まれる全てのコードはデプロイ可能はい二つ目

新しい仕事をするときには説明的に命名されたブランチを作りましょうっていうことがつうとフィーチャーチケット番号みたいなブランチじゃなくてフィーチャーアドニューペイメントタイプスみたいなアドニューペイメントタイプスそんなそういう説明的な命名のブランチを作りましょうっていうことらしいですへーみたいなこれ似たような機能作るときどうするんだろうと思うんですけどねまあまあまあはいで

3つ目ローカルブランチでコミットをして定期的にリモートにプッシュすることこれは普通4つ目フィードバックやヘルプを求めたり自分の作ったものについてメインブランチにマージをする準備ができたと考えたときはプルリクエストを開くことこれも普通プルリクエストがアプローブされたらメインブランチにマージすること最後メインブランチに成果物がマージされたらすぐデプロイすべきであるここはちょっと違うかもしれない

今言った原則的にはそんなにGitFlowと変わらないなと思いますがデベロップブランチがないというのが大きな違いですね環境自体もローカルと本番しかないそれは分からないですね例えばメインブランチに開発

メインブランチのコードが開発環境にあることもあるんじゃないですか例えばですけど多分デブにデプロイしたのかテストなのかなステージングにデプロイしてそこで多分テスト回してOKだったらプロダクションに行くんでしょうから割とこれ思うとCICD前提のフローなように感じてます僕はシンプルでいいなこれの良いところ3つ今回紹介する中ではGitHub Flowが一番シンプルっていうのが一つ目シンプルですね

2つ目シンプルなワークフローなのでCICDとの相性がいいとこれはワークフローというか自動テスト回す対象さっき言ってたGitフローだと多分デベロップとメインとリリースかに対してCICDのパイプライン組まなきゃいけなかったりすると思うんですけどこのGitHubフローについてはメインだけ

にパイプラインというか自動テストでないしデプロイの仕組み入れとくだけでいいので相性がいいですよっていう話をしてます3つ目が小さいチームとプロダクトに向いてる確かにねこれなんかあの僕個人でもそのGitHubでコードをプッシュしたりしてましたけど別に自分のブランチこれでいいやんっていう気がしますね僕これでやってる時ありますね本当に簡単にしてってことですよねそうそうそうわかる

はいっていうのが良いところ3つシンプルですよってところですねチャレンジのところは2つ1つ目は複数バージョンのプロダクションコードを管理するようにできてないと2つ目はデベロップブランチがないので商用環境でバグが発生しやすくなっているとまあそれはそうだとなのでこれパイプライン組まないとパイプライン組んだ上で

メインが勝手にプロダクションに行くようになっててテストされないようになってるとバグが入り込みますテストされるってバグが入り込みますねテスト抜けちゃうやつだったらちゃんとステージング環境とか使ってればあんまり変わんないんじゃないかなって気もするけどねこの原則にめちゃくちゃ乗っとるとメインブランチに成果物がマージされたらすぐデプロイするべきであるって書いてるんで変わるっちゃ変わるんじゃないですか主導テストしないってことなんですよねきっと多分メインでは

多分フィーチャーで自分で変更を適用して自分のフィーチャーブランチの中でしっかりテストしてねっていうことなんですよね多分ねこの他の影響を含め変わる?変わんない?ステージング環境に最初デプロイするみたいなフローを踏んでおけば結局手動テストしてからいけるのかなと思ったけど

そういうことじゃないんじゃないですかねステージングに入れるっていう入れてテストするんじゃないと思いますフィーチャーでテストするんだと思いますステージングに入れたらそこでOKで承認をしたら本番環境でデプロイすればいいんじゃないかなそのテストって多分自動なんですよね主導なのかどっちでもいいと思うけどステージング環境に入れる

入れたらギットフローみたいな挙動になるんじゃないかっていうことじゃなくてですかブランチはメインしかないけどメインをステージングにデプロイしてテストが終わったら本番環境に同じブランチをデプロイするっていうイメージだったけどそれはそうだと思いますそうすればテストも普通にステージングでやってるから大丈夫なんじゃねっていうです

ステージングGitFlowの考え方寄りな気がしましたそれがGitFlowはどっちかというと特徴はリリースブランチがあることな気がするとはいえ毎回確認しなきゃいけない例えばですけどGitFlowだったらデベロップが一通り落ち着いたら一気にやればいいけどGitHub Flowはフィーチャーをマージするたびにちゃんと試験しなきゃいけないんですよね

そこの手間はあるかもしれないなと思いました今話してて確かにマージ間違えたマージされた瞬間にデプロイしないと逆に複数一気に入ったことによるバグとかあるじゃないですかそういうのを防げていいのかなって思いましたそうですねだから大人数に向いてないんですねそうやっていろんなフィーチャーブランチが一気にめちゃめちゃ動いて一気にガッとマージされるようなチームには向いてない確かに鬼デプロイ待ち行列とかできたりするそうそうそう

個人開発とかなるべくこれでいいのかなとか思ったりしましたデプロイ行列が最後いきますねGitLab FlowですGitLab Flowはですねワークフローを明確に定義するという考え方がコアにあってどんなものかというとですねほぼGitHub Flowなんですけどインビロメントブランチっていうのがありますほう

これは何かというとプロダクション、プリプロダクション、リリースの3つのブランチをシチュエーションに分けて使うらしいですプロダクション、プリプロダクションあとリリースステージングみたいなものですよねプリプロダクションってメインブランチはリリースしてるやつと一緒じゃないらしいですメインはリリースしてるやつと一緒ではないはいこれはGitFlowと近いうんうんうん

フィーチャーブランチは機能追加とバグフィックスの2つの役割だからGitFlowでいうホットフィックスの役割もフィーチャーブランチが持ってる全体像見失ったかもまず全部で何のブランチがあるんでしたっけメインメイン

フィーチャーフィーチャープロダクションプリプロダクションリリースプロダクションプリプロダクションリリース5つのブランチがあるんですねただこれは全部使うわけじゃないのかもしれないですねさっき言ったプロダクションプリプロダクションリリースは本番っぽいやつが3つぐらいあったらむずいなそうですねさっき言ったリリースどうやって使うかというとですねGitLab Flowはい

リリースサイクルというかちょっと流れをおさらいというか全体から見てみるとですねGitFlowとGitHubFlowの真ん中ぐらいでさっきプリプロダクションリリースって話をしてましたけどこれはチームによっていいのを使ってねっていう意味合いでプロダクションイコールリリースかもしれないなのでメインがあって

よっしゃリリースしようと思ったらそこからプリプロダクションにブランチを分けてステージングですこれがでプリプロダクションでテストして問題ないわって言ったらプロダクションっていうような形がGitLab Flowですねで直すときはフィーチャーで直しちゃうのでGitFlowよりは若干シンプル

とはいえさっきのプリプロダクションとかリリースとかあの辺は好きにやってねって感じなので構造化されきってねっすなるほどじゃあその現場の環境に合わせて柔軟にやってくれよなみたいなそうですそうですっていうのがメリットはGitFlowよりは簡単だけどチャレンジポイントとしてはGit

GitHub Flowの方がシンプルだしGitFlowの方が構造化されてるよねっていうところではあるのかもしれないですねただこれはデベロップブランチもないので逆に言うとメインがデベロップの役割しちゃってるところはあるんですけどそうだよねそれはちょっと薄々思ってましたそうですそうです

っていうのが間のGitLab Flowっていうような形ですねなのでちょっと軽くおさらいするとGitFlowは最初に言ったメインデベロップフィーチャーリリースホットフィックスでしっかり各作業の名目ごとにブランチが分かれてバッチリやるやつがGitFlowでメインとフィーチャーだけでススッとシンプルにやっちゃうのがGitHub Flow間がGitLab Flowというところでなるほど

複数ライブラリ管理するならGitFlowちっちゃいプロダクトシンプルにやるならGitHubFlowGitHubFlowお前はなんでいるって感じですねすごいすいませんふざけちゃいましたすいませんねメンペキさんのGitの簡単な使い方っていうタイトルにお題に対してはそってたかわかんないんですけど

今日はGitブランチ戦略お話しさせていただきました自分のところのGitブランチ戦略どうかなというところで考えてもらえればなと思いますこのまま少しだけアフタートークですか最近僕勉強してるんですけど英語トークなんですけどトイック勉強してるとブレームっていう単語にぶつかりましてGitブレームってあるじゃないですかGitブレームコマンドはGitブレームファイル名かな

ってコマンドを打つとそのコードの書く行をどこのどいつが書いたのかが一行ずつ表示されるっていうどういう時に使うかっていうとうわバグやんってなった時にこのバグのコード誰書いたんだいつ入ったんだって言った時にGitBraveで調べて

今いない何々さんが何月何日にここのコードこうしてるっていうのを見つけるときに割とGitBrain使うなって思うんですよ12ヶ月前とかで出るよねGitBrain打つと例えばVSコードだったらGitBrain打つと今その開いてるコードにそれが出てくるってことですかGitBrainコマンドはCUI上に出てくるかなCATコマンドとかと一緒でひょっとしたらプラグインとかで

VS Codeでそのまま表示するとかもできるのかもしれないですねたぶんVS CodeでGitLensかなんか入れてると右側に出てきますねあれがCI上に出てくるのかなるほどブレイムっていう単語ですよこれどういう意味かっていうと2つ意味があってあれだよね音楽隊だよねそれブレイメンやん

ブレイムはですね名詞だと責任なるほどねGitブレイムってこのコードの責任誰なんやっていうコマンドなんやってちょっと思ったんですけどこのブレイムは名詞と動詞の動きがありまして動詞の方がですね誰々のせいにするっていう動詞の意味なんですねすごいなと思って悪意あるなすごくない?確かに批評するとかそういう意味かと思ってたわいや誰々のせいにするですねそうなんだうん

性にするっていうのはその単語帳を作った人のさじ加減なんですけど言語学的な面白さがあって責任とその責任をどう自身にした結局日本語にしたら別の言葉ですけどブレイムって別に英語だったら同じ単語じゃないですかローカルじゃなくてネイティブの人たちがノリで動詞的に使うと誰々の性にするっていうニュアンスになるんだって思うと

ギットブレイムも責任と誰々のせいにするっていうのは同じことというかニュアンスとしてなのでギットブレイムは誰のせいだって確かに探してるなと思ってわかるわっていう今まで開いてなかったギットブレイムの扉が開けた気分がついに開けた開けましたね

スッと入ってきましたその単語スッと入ってくるあるよねこれまで意味知らずに使ってた単語を知ると急に見え方変わるみたいな変わるっていうので最近本当にエンジニアのインプットできてないんですけどブレイムという単語を通じてそういう学びがあったので共有でしたおー

僕はGit共有いいですか僕最近ですねTUITUIってターミナルUIの略かな多分ターミナルで使うGUIみたいなツールですねGitUIってのを使ってるんですけどこれ結構使いやすくておすすめですねこれ多分Git簡単に使えます言ってくれた簡単な使い方簡単に使えますこれじゃあ僕もいいですか1個いいよ

ベースコードの拡張機能でGitGraphっていうのがあるんですけどあれなんでしょう本当グラフっていう通り見た目で線が何系っていうんだろう樹形図みたいな樹形図みたいなやつ経歴が多分メインが1本バーって伸びててそこから切ったブランチがいついつのやつでコミット番号何出せないよみたいなのもちょっと見れたりとかっていうので

いつマージしたとかもいろいろ見れるのであれ結構視覚的にGitの動きを見れてGitグラフちょっとおすすめです分かる最初Gitって何のためにあるとかどういう動きしてるとか分かりづらいからそういう視覚的なやつがあるといいですね僕も最初ソースツリーとかも普通に出るんですけどソースツリーでそのグラフ見てるときに急に点形が降りてきましたね

Gitの意味が分かった分かりますあの線の流れが伝わってくると見やすくていいですよねだいたいそれだけ右側にオリジンと今ローカルがブランチそれぞれどこの位置にいるかとかも出るじゃないですかあれとか見てそれで閃きましたねGitについて分かる理解が深まるありがとうございます

というわけで締めますねはいメンペキさんお便りありがとうございましたありがとうございましたゼロ年でねソリッド原則とかGitとかに興味持つの何事かって思うんですけど本当にいいですねエンジニアではないっていう違いますだから多分踏み込むところがなんかエゴい気がするんでソリッド原則とかDDDとかって言ってたと思うんですけどPythonスクリプトをたまに書くだけだったら別にいらないですもんねそうなんだよ

でもまあそうやって学ぶの素晴らしいですねすごいこの辺が楽しいのはなんかわかるぜひ続けてくださいはいはいというわけでお便りありがとうございましたありがとうございました

では最後に宣伝でハッシュタグひまじんプログラマーでSNSのXでフィードバック募集してますので好きなGitのコマンドその系のツールポストお待ちしてますお待ちしてます説明欄から番組へのお便り質問要望をお待ちしてますのでお気軽にお願いいたしますなんでもどうぞお気軽にあと各種ポッドキャストプラットフォームでの高評価ところをお待ちしてます

僕らランキング上がるといいなと本当に思っているのでぜひともお願いいたしますご協力くださいでは引き続きお便りお待ちしていますお願いしますバイバイ

さあ皆さん次の商品は目玉商品ですこちらめちゃくちゃでかいエンターキーわー大きいこれがあるとストレス発散生産性アップ快適な睡眠もえ枕にしちゃうんですかこちらの商品はお値段なんと1024円わーお2の10乗

そして今番組終了1時間以内にGoogleフォームよりお便りを送った方はちっちゃいスペースキーも付いてきますポケットに入れて持ち運べますね番組の高評価フォローもすると会員割引なんと90%オフほぼただ今すぐご応募