Gitのコミットメッセージの書き方（2023年ver.）
本記事のモチベーション 約8年前、Gitを使い始めたときに以下の記事を公開したところ、想像以上の反応をいただきました。 当時はSubversionからGitに移行し、試行錯誤をしている中だったこともあり、多くの反応をいただけたことはモチベーションのひとつでした。 ただ、時が経ち、当然かもしれませんが現在は当時と違う書き方をしており、思想として変わっていない部分はあるものの、今でもときどきLikeをいただく中で、アップデートを全くしないのは誠実じゃないなと感じていました。 というわけで、現在のフォーマットも数年後には変わっている可能性が高いですが、その時々のスナップショットを公開することにも何らか意味があるかなと思い、「今の僕はこうコミットメッセージを書いているよ」というのをまとめました。 Gitを使う環境 開発フローやホスティングサービスごとのUIのdiffによって、最適なフォーマットは変
2022年に試した開発ワークフロー関係の機能やツール - Kengo's blog
数えてみたら意外と数あったのでまとめます。 release-please Google謹製のリリース自動化ツール。monorepo対応のRelease Drafterという感じですが、リリースはDraft Releaseの安定版への昇格ではなく、PRのマージによって行います。PRでリリースするという点ではgit-pr-releaseぽいですが、ブランチは main だけでリリースブランチは無い感じ。changesetsよりはとっつきやすい印象です。 github.com 例えば↓のようなワークフローを用意すれば、モジュールごとにGitHub Releaseを作成するためのPRを自動作成できます。 初期セットアップでJSONファイルを2つ作る必要があるのが若干面倒ですが、それさえ越えてしまえば考えることは少なさそうです。 # .github/workflows/release-please.
「メンバーを信用していないのでは？」 “ある指摘”から始まったLINEアプリ開発チームの生産性改善施策
2021年11月10日と11日の2日間、LINE株式会社が主催するエンジニア向け技術カンファレンス「LINE DEVELOPER DAY 2021」がオンラインで開催されました。そこで竹下秀則氏が、大規模クライアントアプリ開発チームの生産性を改善した仕組み化について紹介しました。まずはチームの成長と課題について。 LINEのクライアントアプリ開発チームの効率化事例 竹下秀則氏：みなさん、こんにちは。今日は「大規模クライアントアプリ開発チームの生産性を改善した仕組み化の数々」というタイトルでお話しします。LINE福岡開発1室所属のエンジニアリングマネージャー、竹下と申します。よろしくお願いいたします。 さっそくですが、本日のアジェンダはこちらになります。まずは私がマネージャーとして所属している、今日お話しする改善の舞台となったチームについて紹介します。 次にそこで直面した課題の数々について赤
【クラウドエンジニア向け】無償公開されている講義資料・研修資料リンク集 - Qiita
Cybozu 2019年エンジニア新人研修 内容 HTTP/DNS Linux ソフトウェアライセンス Git/GitHub Webアプリケーション基礎 ソフトウェアテスト＆テスト自動化 Chrome Developer Toolsの使い方 データベース Docker Webアプリケーションセキュリティ Linux サーバの CPU やメモリリソースの管理について 実践 Go 言語 Kubernetes を使った開発入門 CI/CD スキーマファースト開発ハンズオン GraphQL編 Cybozu 2020年エンジニア新人研修 内容 Webアプリケーション基礎 HTTP/DNS ソフトウェアライセンス スクラムトレーニング 品質保証活動に関するテスト全般からテスト自動化まで HTTPサーバー開発 デザインの役割と関わりかた セキュリティ アクセシビリティ Chrome Developer
GitHubのawesomeリストが本当にawesomeなものばかりだから一度見てほしい - Qiita
伝えたいことは全てタイトルに書いた。 動機 https://github.com/topics/awesome を眺めていて本当にawesomeなものばかりだった (割にあまりどこにもそのawesomeさが書かれていないように見えた) ので書く。 awesomeリストとは GitHub で使われる慣習的なリポジトリについてまとめてみた#awesome より: 「特定テーマに関するキュレーションを行うリポジトリ。Markdown のリスト表記で一覧化するのが一般的。また、Contribution も受け付けている（人気のあるリポジトリはガイドラインも厳しめ）。」 Where? ここのことです: https://awesome.re/ 画像はリポジトリから引用。 What? What is an awesome list? よりDeepL翻訳 awesome マニフェスト もしあなたのリストを
GitHubでの業務ソースコード流出 背景にIT業界の二極化と多重下請け構造｜楠 正憲（デジタル庁統括官）
45歳のプログラマーの男が仕事で書いたコードを年収判定のためGitHubに上げて、複数企業の業務で使われていたコードの一部が流出した。GitHubは本来、公開して構わないオープンソース等のコードを共有する場で、年収判定サイトは、コミュニティでの活動を評価に結びつけようというコンセプトだった。しかし男は業務として開発した商業機密として保護すべき顧客のソースコードを不当に持ち出して、自分の年収を判定してもらうために丸ごと公開してしまった。 GAFAはじめネット企業を中心に、自社サービスを構成する部品で汎用的に使えるコードをGitHubなどを通じてオープンソースとして公開する動きが広がっている。一方で伝統的なシステム開発では、ソースコードは委託した業務の重要な成果物、秘匿すべき商業機密として組織内で管理することが一般的で、開発環境からはGitHubなどのサイトにアクセスできないよう遮断している場
悪いコードを憎んで人を憎まず！ プルリク送付前に心がけたいコードレビューのコミュニケーション術 - エンジニアHub｜Webエンジニアのキャリアを考える！
悪いコードを憎んで人を憎まず！ プルリク送付前に心がけたいコードレビューのコミュニケーション術 コードレビューを円滑に進め、より学びを促進するために重要な「コードレビュー時のコミュニケーション」について、現役エンジニア・池田 惇さんの経験とともに考えてみます。 アプリエンジニアの池田 惇（いけだ・じゅん／@jun_ikd）です。 コードレビューとは、エンジニアにとって毎日発生する作業であり、「コードを書く」という行為と等しく重要なタスクの1つです。同時に、ただ漠然と「粗探し」をするだけがレビューの目的ではありません。特に若手のエンジニアにとっては、先達のエンジニアのコードにじっくりと触れ、学びを得て、さらにチームに自分の持つ知識・技術を還元する、大事な機会でもあるのです。 今回はコードレビューを円滑に進め、より学びを促進するために重要な「コードレビュー時のコミュニケーション」について、私自
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
『プログラムの実行時間を99％短縮した「たった1行のコード」とは？』へのコメント