技術オッラァ!(挨拶)...ラァ!(再挨拶)どうも僕です。今日はね、gitについて知ってるようで何も知らない系女子高生であるお前に向けて、gitについて最近ちょっとわかってきてる俺が、耳たぶが大根おろしになるほどの激情をもってして、この魔法のフライパン片手に、標高4,200メートルを誇る標高1,600メートルから、昨日よりズキズキと脈動せし臀部を強く右に(略gitのチーム開発について多少なり教えていきます。※本意気で書いてないです。この話題は語りつくそうとすると激しく消耗する気がするので。あと今日はなんか頭が痛いし。◆まえがき初歩の説明はしません。しょほほ...(泣)gitの基礎は知ってる前提。gitをこね回しながらチームをリードせねばならなくなった人に向けて話す。ここに書いてあることをお前の現場に適用できるとは思わんほうがいい。gitの運用方法は時と場合に依る部分が大きい。エッセンスだけ学んだらあとはハートでドライブしろ。時と場合に依るゆえに、あまり踏み込んだ説明はしないでおく。チーム開発でのgitについてですから、個人開発は好きにしなよ。masterだかmainだか知らねぇけどpushしまくれよ。◆リモートリポジトリ無論GitHubで問題ないんだけど、AzureDevOpsを試してみて欲しいような。趣旨違っちゃうからここで使い方は説明しないけど。新しいブランチを起こす際は、ローカルで起こさないこと。各gitリポジトリプロバイダ(GitHubやらAzureDevOpsやらGitLabやらGitBucketやら)の操作画面から切ってね。model戦略的にブランチを管理せねば、割と破綻する。コンフリクト祭りになったりもする。flowという名前の戦略をまず理解するべきかも。使うにせよ使わないにせよ。翻訳しましたブランチ種別を把握してほしい。master(main)とdevelopとfeature。masterブランチのことは、以下mainブランチって呼ぶ。masterブランチが神。developブランチはmasterを直に触りたくないから間に挟める緩衝材。featureは開発ブランチ。featureをポコポコはやしてdevelopにマージしていく。この切り方も賛否両論あるんで、真に受けすぎないこと。熱心なアンチがいたりもする。◆開発とプルリクながれdevelopあるいはmainブランチからfeatureブランチを切る。ブランチ名には「feature/」ってプレフィックスつけるよろし。featureをローカルに落としてそこで開発。終わったらfeature切った元のブランチのoriginをfeatureにmerge。origin/developとかする。conflict解消のため。pushfeatureブランチの更新がリモートに飛んで行ったので、使ってるgitプロバイダの画面からdevelopに向けてプルリクとかマージを作成。▼でかfeatureでかい機能については、featureブランチから更にサブブランチを切ること。プルリクが見やすく、追いやすくなる。「機能名/develop」やら「フェーズ名/develop」って名前のブランチを最初に起こせばよいよ。開発ブランチは「機能名/開発内容」とか適当に。」ブランチを切り、開発し、「機能名/develop」ブランチに対してマージをかける。最終的には、まずコンフリクト解消のために「develop」を「機能名/develop」に向けてマージしてから「機能名/develop」を「develop」に向けてマージしろ。◆リリースブランチ戦略は、リリース戦略と密接に絡んでいる。「どういうリリースをしたいか」が「どういうブランチ戦略にするか」を100%左右している。ある程度のプロジェクトであればまず環境が複数あることだろう。基本的には本番環境と検証環境。これがないと何にせよやってられん。本番環境オンリーはありえん。「本番環境」というものと対応するgitブランチを考えたとき、そりゃ当然mainブランチになる。検証環境はdevelopブランチなのかもな。リリースを特に慎重にしなければいけない案件では、mainブランチを検証環境で確認したのち本番環境にリリースするのかもしれない。◆マージは確信と共にリリースとブランチには関連性がある。ブランチに何かをマージする際には留意が必要となる。「鼻から虹色のうどんが出てくる機能実装して」って言われてさ、無事開発終えて、developまでマージ。その後で「引き出しから出てくるワカメを煮る機能」を実装し、これまたdevelopまでマージした。リリース日は半月後だったんだが、「うどん機能のリリース日はやっぱ後ろに倒して、ワカメ機能だけリリースしたい」っていう話になったと。うどん機能は既にdevelopにマージされちゃってる。「develop⇒master」のマージができない。その時に「うどん機能を消すコミット」を作るのは残念極まりないっていうか114514個のファイルに1919810行の変更入っててもう死ぬ。コミットも364364件あるのでrevertも無茶。いうことになるじゃん?できたとしてコミットログが汚物絵巻になる。本当にリリースするものだけをdevelopにマージせねばならん。リリース時期が直近であるものだけ。それまでは各featureブランチで留めるのも手。「develop⇒master」のマージフローを経ずに、各featureブランチからdevelopとmasterそれぞれにマージをかける運用にしてもいい。いろいろな開発中のfeatureを混ぜ合わせつつ検証環境に対して荒れた感じにリリースせねばならん時は、mainとかdevelopとか言わず、もう「検証環境と1対1のブランチ」を作ってしまえばいい。featureをぐちゅぐちゅ混ぜ合わせて検証環境にリリースするためのブランチ。▼マージ用ブランチいま開発しているfeatureブランチに対して別のfeatureブランチをマージするのは危険。ふたつの機能が混ざっちゃって分離できなくなるから。コンフリクトのせいで検証環境用のブランチにマージできない。なったらもう「merge用/機能」みたいにプレフィックスつけてブランチを起こせば良いよ。マージするためだけのブランチを作ってもいい。そこでコンフリクト解消すればよい。元からあったコミットに新しく乗せていいコミットは、ひとつの機能に絞られていたほうが無難です。ポリシーを使用してコードの品質を改善するよくあるのが、作業ブランチのcheckout忘れてdevelopで開発しちゃって、間違ってpushしちゃうやつ。◆gitコマンド暗記重点。別にUI使ってもいいけど、どう考えてもコマンドのほうが楽だと思うぞ。「開発終わり⇒ローカルで変更内容を確認⇒ステージング⇒コミット」までの流れはマウス操作で困らんし楽なのでそうしている。diffとかaddとかしてられん。-p手元に持ってるブランチを全体的にそこはかとなく最新にしてくれる。ハイフンふたつがなぜかひとつにマージされてしまう。WordPress死ね。pushpushする。origin/masterマージ。「origin/master」ってのはよしなに変えろ。