サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
最近は下記のようにライブラリ等のリリースを自動化している。 バージョンを入力するとPull Requestを生成 Mergeするとリリース ラベルの管理 前回のリリース以降にMergeされたPull Requestからリリースノートが自動生成されてほしい。このとき、Keep a Changelogの形式を参考に、変更点が以下の7種類に分類されてほしい。 add change deprecate fix removesecurity other そこで、Pull Requestに予めラベルを付けておくことで、どの節に分類するかを決定させる。またこのようなラベリングの習慣を設けることで、各Pull Requestの粒度の是正もねらう。ラベルを利用したリリースノート自動生成機能自体はGitHubが備えているので、.github/release.ymlでそのラベルを使う旨を指定すれば良い。 この
みなさま、OSSの変更履歴、要するにCHANGELOGやリリースノートはどのように管理しておられるでしょうか。自分はというと、抱えるリポジトリも数百個に増えてきて、まあ要するに細かく管理するのがだるく、最近は変更履歴の管理方法も変わってきました。 CHANGELOGからGitHub Releasesへ 昔は、おおよそKeep a changelogの方式に準拠したCHANGELOG.mdを書いていました。semantic versioningでバージョン管理をしながら、個々のバージョンごとに次のセクションを設けて変更内容を説明するような感じです。 Added Changed Deprecated Fixed RemovedSecurity 今は、新規につくるリポジトリではCHANGELOG.mdは用意せず、GitHub ReleasesにKeep a changelogに似た形式で変更内
対象読者判定フロー 以下の質問にはいかいいえで答えてください。 Q1:GitHub を使用していますか？ はいの方→次の質問に進んでください。 いいえの方→対象外です。すみません。 Q2: ソースコードなどの変更は全てプルリクエストで行って（＝master/main 直コミットはしていない（多少ならOK））いますか？ はいの方→次の質問に進んでください。 いいえの方→まずはプルリクエストベースの開発に切り替えてみてはいかがでしょう？ その後で続きを読んでください。 Q3: リリースノートをちゃんと書いていますか？ はいの方→基本的に対象外です。継続して書いていって下さい。楽をしたいと思ってる場合は続きを読んでください。 いいえの方→あなたは対象読者です！ この記事を読んで、お手軽自動生成でも良いのでリリースノートを作成しましょう！ はじめに 公開しているソフトウエアにバージョン番号を付け
Node.jsを使うメリットは膨大なモジュールを備えるnpmの存在が大きいところです。既存の物を利用するだけでも良いのですが、npmには誰でも簡単にモジュールを公開することができる仕組みが備わっています。 Node.js / npm のインストール ユーザー情報の登録 ユーザー情報をセット npmにユーザー作成 既存ユーザーでログインしたい場合 パッケージの準備GitHubにリポジトリ作成 package.jsonを作成する 依存パッケージの設定 プログラムの準備 その他に必要なファイルを準備 LICENSE.txt README.mdGitHubへpushする npmに公開する npm publish npm installできるか確認 npmで公開したモジュールのバージョンを上げる パッチを当てる メジャー / マイナー バージョンアップ CLIから利用可能なコマンドを登録する p
私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。 要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。 仕方なく自分でまとめたので、増田に垂れ流しておく。 はじめにここで挙げているコミットログは全て実際のコミットログからの転載である。当然ながら各コミットログの著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユースの範囲なら許してくれるだろうと考え名前とプロジェクト名は割愛したが、ここ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? まえがき 私はGit好きの人間です。 もっと言えば、Gitを愛している（Git Lover）と言ってもいいくらいです。 そんな私がなぜこんなタイトルの記事をいまさら書こうと思ったかというと、 いまだにGitの便利さを知らず、Subversionを強い理由もなく使い続ける開発者が多いからです。 そんなわけで 「会社にGit/GitHubを導入するための説得する」 という目的でこの記事を書こうと思います。 Gitの良さってなんだろう？ 実は私もこれまで強く意識して考えたことはありませんでした。 Gitを使い出したら、 それがあるのが当たり前
1リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
