Conventional CommitsとCHANGELOGの自動生成でリリースのユーザ影響をわかりやすくした話 - ドワンゴ教育サービス開発者ブログ
ドワンゴ教育事業 バックエンドエンジニアのtakuminishです。 現在、私は教材入稿ツールの開発チームに所属しています。 教材入稿ツールは昨年の2023年06月に社内向けに正式リリースされた比較的新しいツールであり、リリース当初はリリースノートに関する運用について検討が進んでいませんでした。 リリースノートは開発メンバーが手動で作成しており、内容も前回リリース後にマージされたPRタイトルとリンクを箇条書きで記載しているだけの簡素なものでした。 また、PRタイトルのフォーマットも存在しなかったため、英語で記載されたタイトルと日本語で記載されたタイトルが混在している、ユーザ影響度がタイトルからわからないといった問題もありました。 そこで、教材入稿ツール開発チームではリリースノートの運用として、Conventional Commitsを導入するとともに、conventional-change
Git で会社のリポジトリとかは自動で別のメアドを使うようにする - 宇宙行きたい
仕事でGit使うときとか普段とは違う会社のメアドでコミットとかしたいんだけど、cloneするたびに git config user.email とかするのメンドイよね〜 というかもうだいぶ有名な設定だと思うんだけどたまに知らない人いるので書いておくと includeif 使うと特定のディレクトリ以下のときに読み込む設定を変更できるので便利です。 で、ここまでは普通にGitのマニュアルにも書いてあるんだけど ghq と組み合わせると最高便利になるのでそのへんの設定を書いておきます。 といっても普通に設定するだけだけど .gitconfig には下記のように書いておいて [ghq] root = ~/src [includeIf "gitdir:~/src/github.com/launchableinc/"] path = ~/.config/git/launchable.inc ~/.co
Gitのワークフローについての私のスタンス | おそらくはそれさえも平凡な日々
Gitのワークフロー、好みが分かれる分野で自転車置き場の議論にもなりがちだと感じている。基本的にはプロジェクトの流儀に素直に従い、余計なストレスを抱えないのが良いと考えている。例えば、私はマージコミットを作るのが好みだが、OSS活動等では「squash & mergeして」って言われることもあり、そういうときは当然素直に従うようにしている。 ということで、私のGitのワークフローについてのスタンスについて書いておこうと思う。私と一緒に働く人や、働くことを検討している人の参考になればと思います。もちろん、この辺りは、良い方向に変化もさせていきたい。例えばエントリー内でも触れていますが、私は昔はforce pushを禁止したいくらいでしたが、今は使っても良い、と思うようになりました。 Natureの特にGoでのバックエンド開発はこれに近い感じだとイメージしてもらえればと思います。ただ、できてな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Git研修【MIXI 23新卒技術研修】
