Gitの中身
はじめに Gitで管理するプロジェクトには.gitというディレクトリがあり、その中にGitの管理情報が入っている。その中には、全てのコミットや、いろんなバージョンのファイル、ブランチ、タグといった情報が格納されている。Gitを操作するにあたり、この中身がどうなっているかを理解する必要はないし、もし中身を覚えたとしても、操作方法は変わらないまま、内部実装だけ変更になる可能性もある。それでも、Gitの仕組み、特に様々な情報が.gitにどのように格納されているかを知っておくのは二つの理由から有用だと考える。 一つ目の理由は、「物が動く仕組み」を知っておくことが教養だからだ。車を運転するのに、アクセルを踏めば進み、ブレーキを踏めば止まり、ハンドルを回せば曲がることを知っていれば十分だ。しかし、シリンダーにガソリンが噴射され、ピストンで圧縮したところで点火し、爆発する力でピストンが押される、という直
韓国、政府のオンラインストレージが火災で焼失 8年分の業務資料858TBが消滅か バックアップなく「気が遠くなる」 現地報道
韓国の政府職員が利用する業務用クラウドストレージ「G-Drive」に関する機器が火災で焼失し、8年分の業務資料に当たる858TBのデータが利用できなくなったと、朝鮮日報が10月2日（現地時間）に報じた。バックアップも存在しないという。 報道によれば、G-Driveは公務員が文書共有などに使う政府用のクラウドストレージで、米Googleのクラウドサービス「Googleドライブ」とは無関係。公務員1人につき30GBのデータ容量を提供しており、韓国の行政機関「行政安全部」は各省庁に対し、全ての業務資料は社内PCに保存せず、G-Driveに保存するよう求めていたとしている。 G-Driveは2024年8月の時点で、74省庁の職員12万5000人（政府職員の約17％）が利用しており、858TB（A4用紙4495億枚相当）のデータを扱っていたという。その容量からバックアップもできておらず、G-Driv
はじめに nekogata.hatenablog.com を読みました。 オーナーシップを阻害する構造的な問題について丁寧な分析がされていて、なるほどと思う部分が多かった。しかし、私はこの問題の核心はもっとシンプルなところにあると考えている。 エンジニアが身銭を切っていない。それだけだ。 構造を変えても、制度を整えても、身銭を切らないエンジニアは責任を取らない。逆に、どんな環境でも身銭を切るエンジニアは結果を出す。言い方はなんでもよいが私はそういう覚悟のキマったエンジニアを何人も見てきた。 このブログが良ければ読者になったり、nwiizoのXやGithubをフォローしてくれると嬉しいです。では、早速はじめていきます。 身銭を切るとは何か 身銭を切るとは、「リスクと責任を自ら引き受け、成功すれば報酬を、失敗すれば代償を受け入れる覚悟を持つこと」だと、私は理解している。 ナシーム・ニコラス・タ
Note 本記事の内容は Linus 氏の発言が人を傷つける場合に筆者がそれを良しと考えるといった意図はございません 少し古い記事になるが、 Linus Torvalds 氏 の GitHub に対する苦言が記事になっていた。 LinuxカーネルにNTFSドライバーが追加、トーバルズ氏はGitHub経由のマージに苦言 - ZDNet Japan Linus 氏が GitHub について苦言を呈するのは今に始まったことではない（後述）が、 別に GitHub のすべてを否定しているわけではない。[1] では一体何が不満なのか。Linus 氏の理想とする git の開発フローを考察した上で、整理してみたい。 Linus 氏の理想 結論からいうと、 「意味あるコミットを作れ」「コミットを大事にしろ」 という思想が伺える。 では 「意味あるコミット」「大事にされたコミット」 とは何なのか。 筆者な
はじめに Anthropic といえば、最近はコード生成ツールが大きな話題になっていますよね。 ＡＩ企業アンスロピック、今年の売上高30億ドルに急増へ 売上高を牽引しているのはコード生成機能です。グーグルの親会社であるアルファベット（[GOOGL.O](https://jp.reuters.com/markets/companies/GOOGL.O)）や、アマゾン・ドット・コム（[AMZN.O](https://jp.reuters.com/markets/companies/AMZN.O)）が支援しているアンスロピックは、コンピュータープログラミングに特化した AI として知られています。 このコード生成機能を活用する際に使用するのが、CLI コマンドの claude です。このツールの完成度は非常に高く、最近ではコード生成時に積極的に利用するエンジニアも増えてきています。 この cla
GitHub上のsensitive dataを削除するための手順と道のり | メルカリエンジニアリング
Advent Calendar day 7 担当の vvakame です。 予告では Apollo Federation Gateway Node.js実装についてポイント解説 としていましたが、社内各所のご協力によりAdvent Calendarの私の担当日に間に合う形で公開できる運びとなりました。そのため告知とは異なりますが GitHub上のsensitive data削除の手順と道のり をお届けしていきたいと思います。 メルペイVPoE hidekによるday 1の記事で振り返りがあったように、今年、弊社ではCodecovのBash Uploaderに係る情報流出という事案が発生しました。当該インシデント対応において、プレスリリースにも記載のある通り、ソースコード上に混入してしまった認証情報や一部個人情報などの機密性の高い情報（sensitive data）について調査を実施し、対応
📌 はじめに Pythonで開発を行うにあたり、リンタやフォーマッタ、パッケージマネージャ等のツールの選定は非常に重要な問題です。一方で歴史的な経緯もあり、沢山の選択肢から何を選ぶべきか情報がまとまっていないように感じました。この記事では2021年9月時点でモダンと言えるであろう開発環境を紹介します。基本的にはシェアが高いこと、著名なパッケージで使用されていることを主な選定理由としており、また特定のエディタに依存しないことを前提とします。 本記事で紹介する内容は一つのテンプレートに近く、必要に応じてカスタマイズするもよし、そのまま使ってもよし、として参考になればと思います。(CI/CDについてはPythonとは独立した問題なので触れません。またドキュメント生成はSphinxを推しますが、必須ではないので今回は割愛します。) 📄 要約 "モダン"な開発環境を箇条で列挙すると下記の通りです
本記事のモチベーション 約8年前、Gitを使い始めたときに以下の記事を公開したところ、想像以上の反応をいただきました。 当時はSubversionからGitに移行し、試行錯誤をしている中だったこともあり、多くの反応をいただけたことはモチベーションのひとつでした。 ただ、時が経ち、当然かもしれませんが現在は当時と違う書き方をしており、思想として変わっていない部分はあるものの、今でもときどきLikeをいただく中で、アップデートを全くしないのは誠実じゃないなと感じていました。 というわけで、現在のフォーマットも数年後には変わっている可能性が高いですが、その時々のスナップショットを公開することにも何らか意味があるかなと思い、「今の僕はこうコミットメッセージを書いているよ」というのをまとめました。 Gitを使う環境 開発フローやホスティングサービスごとのUIのdiffによって、最適なフォーマットは変
文章でリストを表示（少し詳細あり） fix: バグ修正 既存の機能の問題を修正する場合に使用します。 hotfix: 緊急対応 稼働中のシステムのバグ修正など、緊急性が高い修正を行う場合に使用します。 add: ファイルや機能の追加 新しいファイルや機能を追加する場合に使用します。 feat: 新機能・新規ファイル追加 新しい機能やファイルを追加する場合に使用します。 update: 機能修正 既存の機能に問題がなく、ただし修正を加えたい場合に使用します。 change: 仕様変更による機能修正 仕様変更により、既存の機能に修正を加えた場合に使用します。 clean・refactor: リファクタリング コードを修正し、改善する場合に使用します。 improve: コードの改善 コードの改善をする場合に使用します。 disable: 機能の無効化 機能を一時的に無効にする場合に使用します。
リリース頻度を毎週から毎日にしてみた - NTT docomo Business Engineers' Blog
目次 目次 はじめに NeWork とは リリース頻度変更の背景 それまでの運用 課題 実現方法 解説 日次でワークフローが起動するようにする main ブランチの HEAD にタグが付与されていなければ付与する develop に差分があれば main へのマージを自動で行う 細かな工夫点 main の内容を develop に自動で取り込む 祝日はリリースしないようにする 自動リリース・自動 develop → main マージの制御 Slack にリリース結果を通知する stg 環境に変更内容を通知する その他の考慮 上司への事前説明の省略 スプリントレビュー前のリリース リリースノート 品質面 リリース頻度を変えてみて おわりに はじめに こんにちは、NeWork 開発チームの藤野です。普段はオンラインワークスペースサービス NeWork のエンジニアリングマネジメントをしています
自分はこれまでの仕事で、バグ修正や機能追加でPullRequestを送るときに、考慮の抜けもれやケアレスミスが非常に少ない方であると思っている。振り返ってみて、これは自分に課している習慣が大いに効いていると思っているので、メモしておく。 毎回のcommit時 必要な部分だけをgit addし、git diff --cachedによって差分をセルフコードレビューした上でcommitする PullRequest作成時 filesの内容をセルフコードレビューし、直した方が良い部分は直す + わかりにくい部分にGitHub上でラインコメントを行う + コード上にコメントを残した方がいいならコメントする ユーザーの導線に影響するコードなら、必ず自動テストだけでなく、自分自身でユーザーの行動をトレースし、違和感がある部分が存在しないかチェックする。チェックした流れについては、PullRequest上に
Gitのオブジェクトの中身
はじめに Gitのインデックスの中身、Gitのブランチの実装に続く、Gitの中身を見てみようシリーズです。Gitが管理するオブジェクトの種類や中身について見てみます。基本的にはPro Gitの10. Gitの内側をまとめなおしたものです。 オブジェクトの種類 Gitは、内部でファイルやコミットを「オブジェクト」として.git/objects以下に保存しています。オブジェクトには以下の4種類があります。 blobオブジェクト： ファイルを圧縮したもの。ファイルシステムの「ファイル」に対応 treeオブジェクト： Blobオブジェクトや別のTreeオブジェクトを管理する。ファイルシステムの「ディレクトリ」に対応 コミットオブジェクト： Treeオブジェクトを包んだもの。コミットのスナップショットに対応するTreeオブジェクトに、親コミット、コミットメッセージなどを付加する タグオブジェクト：
コードレビューにずっと苦手意識を持っていた。レビューは時間がかかるし、あまり気が乗らない。 がんばってやっても、うまくできたのかどうか自信が持てない。 もちろん、世にあるコードレビューに関する書籍や記事などはいくつも読んだ。 そこには、コードレビューをするときの観点や、コードレビューで望ましい言葉づかいなど、ためになることがたくさん書かれていた。 それでも、やはりコードレビューが苦手なことに変わりはなかった。 だけど最近ようやく、こうすればレビューをうまくこなせるのではないかという出口が、なんとなく見えはじめてきた。 この記事では、ぼくなりにたどり着いた、プルリクエストのレビューを上手に行うための心構え、つまりいかにしてレビューのつらみを減らすかについて書く。 目次 なぜコードレビューはつまらないのか われわれは、なんのためにコードレビューをするのか レビューのコスト レビューの観点 文化
先日、我が家の長女と一緒に旅行していたときのことだ。駅のホームで電車を待つあいだ、私はスマホでX（旧ツイッター）を開いた。そしてついうっかり、私がフォローしているユーザーの投稿（ポスト）ではなく、「おすすめ」に表示された投稿を読み始めてしまった。 「おすすめ」には、利用者の特性をある程度まで踏まえてXが選択したポストが表示される。そのため、私がフォローしていないユーザーのポストも流れてくる。一時期はXを所有するイーロン・マスクのポストがやたらと表示されていた。報道によれば、Xがそのように設定していたという。 その選択基準の概要は公開され、「極めて攻撃的な内容」のものは選ばれないとされてはいる。しかし、やはり人の感情を刺激するポストが多く表示される。マスクはXを「対戦型ソーシャルメディア」と呼んだが、それはユーザー同士が争うことでその利用時間や利用者数が伸び、結果として広告媒体としての価値が
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
より良いコミットメッセージを残すことは Git を使った開発をする上で重要なことです。優れたコミットメッセージは、それを読んだ人がコードを理解するのに大いに役立ちます。 では、どのようなメッセージが良いもので、どのようなメッセージが悪いものなのでしょうか？ それについて掘り下げていきたいと思います。 基本的な Git Commit Message の書き方 詳しいところは、以下の3サイトを参照してください。特に「How to Write a Git Commit Message」には基本がすべて書かれています。 How to Write a Git Commit Message https://cbea.ms/git-commit/ Gitのコミットメッセージをうまく作成する7つのルール （「How to Write a Git Commit Message」の和訳記事） https://
タイトルがすべて。 思いついたら手を動かしてしまう性質なので、秘蔵のブランチを大量に持っている。 秘蔵のブランチというのは、動いたけどチームメンバーを説得するのが面倒とか、テスト書くのが面倒とか、だいたい動いているけどやりきるのが面倒とかで main にマージしていないヤツ。 例えばフレームワークのメジャーバージョン上げるブランチとか、依存ライブラリをより一般的/現代的なものに交換するブランチや、より良い設計を思いついたのでガッと書き換えてしまうブランチが多いかな。 だいたい 1 年所属していると 80 ブランチぐらい溜まるので、週 1 つ以上は何か作りかけてる計算になる。 ローカルブランチの数、プロンプトに出しておくかな……。(秘蔵のブランチが溜まってる— Takafumi ONAKA (@onk) March 28, 2017 もちろん自分でいいアイディアだと思っているから実装している
ロジカルなコミットメッセージの書き方
チーム開発におけるコミットメッセージの書き方についてアウトプットします。 コミットメッセージに正解はありません。 組織によって最適な手法は異なるため、参考のひとつにしてください。 要点 フォーマット :Emoji: Title / Reason / Specification / Issue 項目 Emoji - 内容・種類をひと目で分かるように Title - タイトル（概要） Reason - このコミットをする理由 Specification - 言い訳ではなく、このコミット内容になった意図や仕様など Issue - 対応するIssue 作業内容はコードを見ればわかるので、「概要」「変更理由」「意図・仕様」を簡潔にまとめる。 例 コミットメッセージを書く理由 そもそも、コミットメッセージを書く理由は以下の通りです。 ひと目でどんなコミットなのか判断するため 簡潔にコミット内容を説明す
個人開発者のためのコマンドラインGit使いこなし術
英語で先に書いてから翻訳しています どうも個人アプリ作家のTAKUYAと申します。 Gitはコードベースや変更履歴の管理に必要不可欠なツールです。たとえ個人でアプリを開発していたとしても。 僕はデスクトップとモバイルの両方で動作する、InkdropというMarkdownのノートアプリを独りで開発しています。 当アプリはデスクトップ版はElectron、モバイル版はReact Nativeで作られています。 僕は開発作業は基本的にtmuxとvimでターミナル上で行っています。vimによるJavaScriptコーディングのためのセットアップについては前回シェアしたとおりです。 本稿では、僕のGitのワークフローについてご紹介したいと思います。 内容はすでにGitの基本をご存知の方向けとなります。 Gitの操作も基本的にはターミナル上で行っています。 色んなGUIベースのGitクライアントアプリ
OpenAI APIを使ってgit commitメッセージやコードレビューをAIに任せましょう！ - GMOインターネットグループ グループ研究開発本部
2024.09.27 OpenAI APIを使ってgit commitメッセージやコードレビューをAIに任せましょう！ 次世代システム研究室の Y.I です。 OpenAI API を活用してちょっと便利なコマンドを作成したのでご紹介します。作成したものは、「自動Git Commitメッセージ生成」と「コードレビュー」機能です。LangChainやVectorDBなどを利用しなくても、発想次第で便利な機能を作れますので1例としてご覧ください。 機能紹介 Pythonで以下の機能を実現しています。 Git commitメッセージの自動生成 Gitの変更履歴に基づき、適切な日本語のcommitメッセージを生成します。 コードレビューの自動化 Gitの変更履歴に基づき、コードに問題がないかやパフォーマンス改善の提案を行います。 openai apiのtokenを環境変数から取り込み 簡易的ですが
コミット履歴を綺麗にするときの`git commit --fixup`と`git rebase --autosquash` - 理系学生日記
Pull Request(PR)やMerge Request(MR)を作る中で、コミット履歴はできるだけ綺麗にしておきたいものです。 プルリクエストについて - GitHub Docs Merge requests | GitLab ぼくはあまりコミット履歴の綺麗さを気にしない方でした。 しかし大きめのPRやMRをレビューする側に回ると、「変更のまとまり」が追えないと「なぜこの変更をしたのか」が非常に追いにくくなります。 だからこそ最近は、コミット履歴をかなり意識するようになりました。 その時に活躍しているのが、タイトルの通りgit commit --fixupとgit rebase --autosquashです。 git commit --fixup git rebase --autosquash そのほかおすすめ git commit --fixup git commit --fixu
GitHub ActionsからGitHub wikiを更新する - Islands in the byte stream
GitHub ActionsからGitHub wikiを更新したいことがたまにあります。たとえば、何かのメトリクスを見やすく整形したものなど、repositoryのデータを何らかの形で加工したドキュメントを作りたいときです。コード生成したmarkdownドキュメントをコミットしてもいいですが、それよりはシンプルで運用が楽です。 今回は、GitHub repoで管理する原稿の文字数（など）を継続的に見れるページを作ると便利かなと思って作りました。自分一人だったらローカルで適当なツールを叩けばいいですが、同repoを見れる編集者にも共有したいとなると独立したページがあるほうが便利ですからね。 リポジトリはこんな感じです。 github.com 基本的には、 actions/checkout を使って "${{ github.repository }}.wiki" をcloneして編集してpus
Sapling: Source control that’s user-friendly and scalable
Sapling is a new Git-compatible source control client. Sapling emphasizes usability while also scaling to the largest repositories in the world. ReviewStack is a demonstration code review UI for GitHub pull requests that integrates with Sapling to make reviewing stacks of commits easy. You can get started using Sapling today. Source control is one of the most important tools for modern developers,
Kubeshark で Kubernetes の Traffic を眺めてみよう/Let's Look at k8s Traffic with Kubeshark
eBPFでcommit logを調べてみるといろいろと面白そうなものが出てくるな。例えば、TCP-BPF [netdev 2.2]。TCPコネクションのパラメータをBPFで操作できる。さらに最近（バージョン5.5以降）では、輻輳制御もeBPFで実装できるようになっているようだ。eBPFによりカーネルからどんどん機能を追い出してLinuxはマイクロカーネル化するのだという鼻息荒い発表も見かけるが（「eBPF - Rethinking the Linux Kernel」[QCon2020]）、正直これが正しい方向性なのかよくわからない。面白いけど。 eBPFを使っているわけではないが、輻輳制御をユーザレベルで実装するという研究はいくつかある（「Restructuring Endpoint Congestion Control」 [SIGCOMM2018]、「Deploying Safe Use
ContentsBasic project setupThe basic setup consists of four steps: Create the project and source directoriesCreate a package.jsonGet a .gitignore, tsconfig.json, .eslintrc.jsInstall TypeScript & dependenciesNote: This guide uses yarn, but if you prefer npm it has similar commands. # Create project folder mkdir my-project cd my-project # Create source folder and files mkdir src touch src/main.ts sr
GitHub Actionsとtfupdateを使ってTerraformおよびTerraform Providerのバージョンアップを自動化する - ZOZO TECH BLOG
はじめに こんにちは。SRE部MLOpsチームの築山（@2kyym）です。 Infrastructure as Code（IaC）が一般的になり、またパブリッククラウドをフル活用したインフラ構築が当たり前となりつつあります。そんな中で、インフラの構成管理にTerraformを用いているチームも多いのではないでしょうか。本記事ではTerraformを用いたインフラ構成管理において避けては通れないTerraformやProviderのバージョンアップを自動化し、IaCの運用負荷を削減する方法をご紹介します。MLOpsチームでの運用を参考に、具体的な設定やハマりどころを交えつつ解説できればと思います。 目次 はじめに 目次 Terraformとは MLOpsチームにおけるTerraform運用の背景 Terraform管理の対象リソース Terraform運用において生じた課題 tfupdate
OSSコントリビュータになろう ― Deno編
Copyright (c) 2018-2020 the Deno authors. MIT License. この記事は Deno Advent Calendar 2020 24日目の記事です。 23日目は -> （あとで埋める） 25日目は -> Deno が Node.js に依存しなくなった はじめに こんにちは、@magurotuna です。 2020年ももうそろそろ終わりですね。みなさんはどのような1年を過ごされたでしょうか？ 僕は、初めての転職をしたり、OSSコントリビュートを始めたり、といった1年でした。 OSSコントリビュートに関しては、去年までは「凄腕のエンジニアがやるものであって、平凡なエンジニアである僕はその恩恵に預かるだけ……」と思っていましたが、いざやってみると、まったくそのようなことはなく、さまざまな方面からOSSに貢献することができるということが分かりました。
普段は基本的にMariaDBの動向は全く追って無いです。 でも先日、MariaDB 10.5 のfsync()発行が少なく性能が良いのは何故なのかちょっと見てほしいと言われて、 mariadb-10.5.9.tar.gz をざっと見たらあっという間に原因特定。 「fsync()を待つべきなのに待ってないから」 只の不正と判明。 動作としては、 innodb_flush_log_at_trx_commit = 1 でも innodb_flush_log_at_trx_commit = 2 でも 並列度が上がると多くのトランザクションが innodb_flush_log_at_trx_commit = 0 の動作と同等となってしまうようです。 待たないのだから速いに決まってる。こんな不正なものと比較されるのは腹立たしいです。 指定のLSNまでのwriteやflushを終わらせる log_wri
Conventional CommitsとCHANGELOGの自動生成でリリースのユーザ影響をわかりやすくした話 - ドワンゴ教育サービス開発者ブログ
ドワンゴ教育事業 バックエンドエンジニアのtakuminishです。 現在、私は教材入稿ツールの開発チームに所属しています。 教材入稿ツールは昨年の2023年06月に社内向けに正式リリースされた比較的新しいツールであり、リリース当初はリリースノートに関する運用について検討が進んでいませんでした。 リリースノートは開発メンバーが手動で作成しており、内容も前回リリース後にマージされたPRタイトルとリンクを箇条書きで記載しているだけの簡素なものでした。 また、PRタイトルのフォーマットも存在しなかったため、英語で記載されたタイトルと日本語で記載されたタイトルが混在している、ユーザ影響度がタイトルからわからないといった問題もありました。 そこで、教材入稿ツール開発チームではリリースノートの運用として、Conventional Commitsを導入するとともに、conventional-change
secretlint を使って機密情報を git commit できない環境を作る | DevelopersIO
AWS アクセスキーなど、機密情報の git commit を防ぐ secretlint の紹介記事です AWSアクセスキーセキュリティ意識向上委員会って何？ 昨今、AWSのアクセスキーを漏洩させてしまうことが原因でアカウントへの侵入を受け、 多額の利用費発生・情報漏洩疑いなど重大なセキュリティ事案が発生するケースが実際に多々起きています。 そこで、アクセスキー運用に関する安全向上の取組みをブログでご紹介する企画をはじめました。 アクセスキーを利用する場合は利用する上でのリスクを正しく理解し、 セキュリティ対策を事前に適用した上で適切にご利用ください。 tl;dr 開発をはじめる前に、次の手順を実行しよう シェルスクリプトの保存 次のシェルスクリプトを ~/.git-template/hooks/pre-commit として保存しよう。 #!/bin/sh FILES=$(git diff
written on Thursday, July 14, 2022 When you maintain a project, publishing new releases can quickly become a chore, so naturally one tries to automate it as much as possible. One release step which is often automated is updating the changelog. We already have git commit messages, so let's gather all the messages since the last tag and "Voilà!" changelog entries for the new version! There is howeve
コミュニティ主体の技術カンファレンスをいくつかオーガナイズしてきた立場の人として、プロポーザルの採択に関わることがこれまで何度かありました。 何度か繰り返していくうちに、自分はこういうことを考えて採択するか決めているな〜というのが年々言語化できつつあるので、そろそろ頭のなかをdumpしてみようかという気持ちになってきました。 数年して考えが変わるかもしれないし、今の時点ではこんな感じのことを考えていたという記録になります。 技術カンファレンスと銘打ってますが、自分の場合は基本全部YAPC::Japanシリーズのカンファレンスの経験がベースになっています。 他のカンファレンスでは事情が異なることもあるとは思いますが、それでも参考になる部分はあるかもしれません。 なお、この記事はあくまで私的な考えの表明でそれ以上でも以下でもないものです。 他の誰かの考え方を肯定したり否定したりといった意図はあ
GitHub - orhun/git-cliff: A highly customizable Changelog Generator that follows Conventional Commit specifications ⛰️
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
初めてPullRequestを対応する前に知りたいGitのコミットについて - ANDPAD Tech Blog
こんにちは！2021年2月にアンドパッドに入社しました、エンジニアの浜田です。 私の経歴として入社前までチームでの開発をほとんどしてきませんでした。アンドパッドに入社して初めてチーム開発をするようになりました。 入社当初、私がPR(Pull Request)を対応する中で教えてもらったことや、他の方が教えてもらっていたことを社内向けに初めてPRを対応する前に知りたいことというタイトルで記事をまとめました。今回はその記事の内容からGitに関してまとめた4点を紹介させていただきます。 はじめに 1. コミットメッセージは1行目がタイトルで3行目から説明 2. 1コミットに複数の対応を混ぜない 3. コミットメッセージに有益な情報を残す 4. レビュー前にGitのコミット整理 まとめ はじめに アンドパッドではGitHub上で開発を進めています。PRのマージ条件の1つにレビュアーのApprove
GitHub - nikochiko/autosaved: Never worry about losing your code. Written in Go
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
ノア・スミス「AIと雇用，ふたたび」（2025年8月30日）
トップ経済学者たちのなかにも，「アメリカ人の一定層で AI による雇用破壊が起きている」と主張する人たちがいる．彼らは正しいだろうか？ 「AI は人々の仕事を奪っているのか」をめぐる論争は，永遠に続くかもしれないし，いずれ終わるかもしれない．現に AI が大勢の人たちの仕事を奪ったなら，そこで論争は終わる．その時点で一方の側が明らかに勝ったことになるからだ．でも，AI が大勢の人たちの仕事を奪ってないときには，論争の決着はつかない．それでもなお「もうすぐみんなの仕事が奪われるぞ」って言い続ける人たちが大勢現れるだろうからね．ときに，今後の雇用の見通しがみんなよりも悪い一部の層を見つけて，「ほら，これこそ AI による一大雇用破壊の始まりだ」とその手の人たちが主張することがある．彼らが間違ってると証明できる人なんて，いる？ つまり，〔上の話に合わせていいシナリオとわるいシナリオを分けると〕い
GitHub now supports SSH commit verification, so you can sign commits and tags locally using a self-generated SSH public key, which will give others confidence about the origin of a change you have made. If a commit or tag has an SSH signature that is cryptographically verifiable, GitHub makes the commit or tag "Verified" or "Partially Verified." If you already use an SSH key to authenticate with G
Laravel + Vue.jsでGoogleカレンダーのクローンを作ろう！！【Laravel8対応】フロントエンド編④｜Yuu's Memo
皆さんこんにちは！！ 前回に引き続き、フロント（Vue.js）側の開発を始めていきます。 Vue.jsに皆さんも大分慣れてきたのではないでしょうか？ 前回は、予定の詳細表示ダイアログを作成しました。 前回までの記事はこちらからどうぞ Laravel + Vue.jsでGoogleカレンダーのクローンを作ろう！！【Laravel8対応】準備編Laravel + Vue.jsでGoogleカレンダーのクローンを作ろう！！【Laravel8対応】API作成編①Laravel + Vue.jsでGoogleカレンダーのクローンを作ろう！！【Laravel8対応】API作成編②Laravel + Vue.jsでGoogleカレンダーのクローンを作ろう！！【Laravel8対応】フロントエンド準備編Laravel + Vue.jsでGoogleカレンダーのクローンを作ろう！！【Laravel8対応】フ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
![[Git] GitHubにGPG鍵を登録し署名付きcommit/tagを行う - ねこの足跡R](https://cdn-ak-scissors.b.st-hatena.com/image/square/e8b782a71fa37c662d76e7cc6954405dad3a74d4/height=288;version=1;width=512/https%3A%2F%2Fcdn.image.st-hatena.com%2Fimage%2Fscale%2F974511cded72016c9f25880b06900907f2360ebf%2Fbackend%3Dimagemagick%3Bversion%3D1%3Bwidth%3D1300%2Fhttps%253A%252F%252Fcdn-ak.f.st-hatena.com%252Fimages%252Ffotolife%252Fk%252Fkatsube%252F20231125%252F20231125073748.png)
エンジニアはちゃんと身銭を切れ - じゃあ、おうちで学べる
Linus Torvalds 氏の理想の git 運用と GitHub
Anthropicで利用されているモダンなPython開発のベストプラクティス
【2021】モダンなPython開発環境の紹介 - Qiita
Gitのコミットメッセージの書き方（2023年ver.）
【Git】コミットメッセージの先頭につけた方が良い単語リスト- prefix集 - - Qiita
コード変更で抜け漏れやミスを少なくするための習慣 - $shibayu36->blog;
コードレビューはつまらないから丁寧なプルリクエストでチームの生産性向上を目指す
「怒り」を商業利用するSNSが「分断」を促進するメカニズム｜社会｜中央公論.jp
git commit --fixup が便利 - Qiita
より良い Git コミットメッセージを書こう - Qiita
branch を寝かせるときは TODO.txt を置いている - id:onk のはてなブログ
How COMMIT Works in CockroachDB
TCP-BPF: Linuxはマイクロカーネルの夢を見るか｜oraccha
Starting a TypeScript Project in 2021
MariaDB 10.5 の性能は不正？
Your git log is not a changelog!
技術カンファレンスのプロポーザル採択のときに僕が考えていること - 時計を壊せ
gitでコミット(commit)前にterraform fmtやtflintを実行したい時はpre-commit-terraformが便利 | DevelopersIO
SSH commit verification now supported - GitHub Changelog
www.gw2.biz
coublood.hatenablog.com
tabigarasu.hatenadiary.jp
bluesky-15.hatenadiary.com
youtu.be
kurokoshusaru.hatenablog.com