お知らせ レバテックラボさんのサイトに、コミットのベストプラクティスと、プルリクエストのベストプラクティスをまとめた記事を寄稿しました。 levtech.jp levtech.jp エンジニアの暗黙知を形式知に お仕事でコードを書いている人は、日々gitにコミットしたり、プルリクエストを作成したりしていると思います。 ただ、「どんなコミットが良くて、どんなコミットが悪いのか」とか、「どんなプルリクエストが良くて、どんなプルリクエストが悪いのか」といった話をわざわざ教えてもらった人はそんなに多くないのではないでしょうか？ せいぜい、先輩プログラマから「このコミットの仕方はイマイチだからこうしようね」とか「プルリクエストにはしっかりdescriptionを書いてください」といった指摘をもらい、「なるほど、そういうもんなのか〜」と徐々に正しいやり方を学んでいく、みたいなケースが多いのでは？と想像
Summary 何となくでも良いのでconventional commitの仕様にしたがってcommitを作る 変更はPR作る直前までcommitしない 3.レビュー以前の変更はfixupとforce pushで既存のcommitに入れる。追加のcommitは作成しない 解説 1. 「何となくでも良いのでconventional commitの仕様にしたがってcommitを作る」について conventional commitとは、「人間と機械が読みやすく、意味のあるコミットメッセージにするための仕様」です。（公式から引用https://www.conventionalcommits.org/ja/v1.0.0/ ) この仕様(の特にコミットメッセージのタイトル部分)に従ってコミットを作るようにします。 タイトル部分の仕様はこんな感じです。 <type>[optional scope]:
AI & MLLearn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry. Generative AILearn how to build with generative AI. GitHub CopilotChange how you work with GitHub Copilot. LLMsEverything developers need to know about LLMs. Machine learningMachine learning tips, tricks, and best practices. How AI code generation worksExplore the capabilities and be
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? これは Git (や Subversion などのバージョン管理システム) にコミットする時により良いコミットメッセージを書くための提言です。この提言は特にメッセージの一行目だけを対象とします。せめて最も重要な一行目だけでも良いメッセージを書いて欲しいからです。提言をズバリ一言で表すと 一行目には要求仕様を書け です。 背景 プロジェクトによっていろいろ慣習の差はあるものの、一般的には「コミットメッセージの一行目は変更内容の要約を簡潔に書け」とされます。特に Git は、各コミットメッセージの一行目だけを取り出してそれを一覧表示するなど
毎日他の人のコミットをながめる文化で生活していると、理由は浮かばないけど「ん？このコミットはなんか気になる」と感じるようになります。それは、新しいことを知ることができたコミットだったり、真似したくなるようなコードが入っているコミットだったり、なんかまずそうな気がするコミットだったり、様々です。 「ん？」と感じてコミットを見直してみても、何が気になったか自分でもすぐにわからない場合があります。そんなとき、気になったことをコミットした人に伝えるために、コミットへのコメントをまとめ始めます。「コミットした人に伝えるため」というように、他の人に伝えようとすることがポイントです。他の人に伝えるためにまとめようとすると、思いの外なにが気になったかまとまるものです。 今回は、メタプログラミングを使ってコードを整理したコミットで「ん？」と感じたときのことについて紹介します。このおかげで「メタプログラミング
前回の時点では「git blameが密になっているところはきっと活発に編集されていたに違いない」という仮説があったわけですが、これは本当のところは、よくわからない。なぜかというと、blameというのは地層のように降り積もったコミットの表面に露頭してるところしか見せてくれないわけです。本当に活発に更新されていたかを知るには、ようするに地質平面図じゃなくて地質断面図が必要なわけ。分かりますよね。 で、それはどうやって作ればいいかというと、gitには便利なgit log -pという、こういうとき便利だけど普段は使い道のなさそーなコマンドがあって、これは生のdiffをすべてだらだらと表示してくれるわけですよ。で、diffからblameを再構成するにはdiffの+行をひたすら集めてくればいいわけだけど、その時-行も一緒に覚えておいて、あるコミットでどのコミットが上書きされたかを覚えておくことができる
「オープンソースソフトウェア(OSS)」と聞いて、あなたがイメージするものはなんですか？ 多くの人は Linux や Apache、Firefox といった成功した大規模なソフトウェア製品を思い浮かべることでしょう。 実は、ウェブ上でサービスを提供する会社のエンジニアたちは、これらとは別の種類のOSSを使って仕事をしています。このブログエントリでは、そのようなOSSを紹介し、それらがなぜ開発され使われているかを説明したいと思います。 ■ウェブ企業におけるOSS開発の実例と合理性 下の図は、Perl で記述される大規模ウェブアプリケーションの一般的な構成を示しています注1。このうち、「自社ロジック」と書かれているところ以外は、全てオープンソースとして開発／公開されているモジュール（ソフトウェア部品）です。各社のエンジニアが密接に協力しながら、ミドルウェアをオープンソースとして整備していること
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
