Git 2.9以降はcore.hooksPathというオプションでグローバルまたはローカルのGitフックのディレクトリを指定できるようになっています。 Gitのcore.hooksPathオプションを利用するとhusky、simple-git-hooksのような追加の依存がなくても、Gitの機能だけでGitフックのコードをバージョン管理して、プロジェクトのセットアップ時にプロジェクトごとのGitフックを設定できます。 📝 類似するGitフックを管理するツールとしてpre-commitやLefthookもあります。これらのツールはGitフックの管理だけではなく、ファイルの種類ごとに実行するコマンドをわけて書けるようになっています。 つまり、lint-stagedのような機能も含むので、この記事で紹介するアプローチ以上の機能も同梱されています。 Node.jsプロジェクトの例 ここでは具体例
歴史改変、してますか？ 私は歴史改変が大好きで、毎日 rebase しています。なので割と毎日 git push -f することになっています。 口で -f と言っても、実際には --force-with-lease --force-if-includes をしているので、これらのオプションのご紹介。 この記事は はてなエンジニア Advent Calendar 2022 の 18 日目です。昨日は id:rokoucha さんで 壊れたデータベースとの向きあいかた - rokoucha でした。 qiita.com -f の危険性 ...--F--G--H <-- main という状態で push した後、H をコミットし直したとしよう。 ...--F--G--H' <-- main \ H <-- origin/main このまま H' (main) を origin/main に p
GitHubには各リポジトリがどういった言語で構成されているのかを表示する機能がある（↓こういうの） デフォルトでGitHubがいい感じにしてくれるが、標準から外れたディレクトリ構成になっていると、意図しない感じになったりすることがある。具体的には、標準とは違う場所に 依存ライブラリが直接置かれている ドキュメントが書かれている と言語の割合が狂う。例えば、↑の画像で引用したリポジトリではJavaScriptのモジュールを作っているが、標準とは少し違う場所にドキュメントを置いている都合で、意図せずCSSやHTMLが合算されてしまっている。気にしなければいいという話ではあるのだが、どうしても気持ち悪い場合はリポジトリルートに .gitattributes というファイルを用意して
Advent Calendar day 7 担当の vvakame です。 予告では Apollo Federation Gateway Node.js実装についてポイント解説 としていましたが、社内各所のご協力によりAdvent Calendarの私の担当日に間に合う形で公開できる運びとなりました。そのため告知とは異なりますが GitHub上のsensitive data削除の手順と道のり をお届けしていきたいと思います。 メルペイVPoE hidekによるday 1の記事で振り返りがあったように、今年、弊社ではCodecovのBash Uploaderに係る情報流出という事案が発生しました。当該インシデント対応において、プレスリリースにも記載のある通り、ソースコード上に混入してしまった認証情報や一部個人情報などの機密性の高い情報（sensitive data）について調査を実施し、対応
# 前置き AWSのSecretをpushしてアメリカから電話が掛かってきてからというもの、GitGuardianからメールが来る度に嫌な汗を掻いている私です。 そんな生活から抜け出すため、 Credentials(秘匿情報)を含んだファイルがないかチェックしてくれるSecretlint と、Gitの特定のコマンドにフックして処理を挟めるGit Hooks を使って、全てのリポジトリでのコミット時にSecretlintを走らせる環境を作っていきます。 なお、私はWindowsユーザーなのでシェルはPowershellで進めていきますが、Unix系のエイリアスを色々追加しているので無意識に使っていたらよしなに脳内変換をお願いします。 Secretlint (opens new window) Git Hooks (opens new window) # 私の環境 git version 2.
タイトルがすべて。 思いついたら手を動かしてしまう性質なので、秘蔵のブランチを大量に持っている。 秘蔵のブランチというのは、動いたけどチームメンバーを説得するのが面倒とか、テスト書くのが面倒とか、だいたい動いているけどやりきるのが面倒とかで main にマージしていないヤツ。 例えばフレームワークのメジャーバージョン上げるブランチとか、依存ライブラリをより一般的/現代的なものに交換するブランチや、より良い設計を思いついたのでガッと書き換えてしまうブランチが多いかな。 だいたい 1 年所属していると 80 ブランチぐらい溜まるので、週 1 つ以上は何か作りかけてる計算になる。 ローカルブランチの数、プロンプトに出しておくかな……。(秘蔵のブランチが溜まってる— Takafumi ONAKA (@onk) March 28, 2017 もちろん自分でいいアイディアだと思っているから実装している
Gitのワークフロー、好みが分かれる分野で自転車置き場の議論にもなりがちだと感じている。基本的にはプロジェクトの流儀に素直に従い、余計なストレスを抱えないのが良いと考えている。例えば、私はマージコミットを作るのが好みだが、OSS活動等では「squash & mergeして」って言われることもあり、そういうときは当然素直に従うようにしている。 ということで、私のGitのワークフローについてのスタンスについて書いておこうと思う。私と一緒に働く人や、働くことを検討している人の参考になればと思います。もちろん、この辺りは、良い方向に変化もさせていきたい。例えばエントリー内でも触れていますが、私は昔はforce pushを禁止したいくらいでしたが、今は使っても良い、と思うようになりました。 Natureの特にGoでのバックエンド開発はこれに近い感じだとイメージしてもらえればと思います。ただ、できてな
個人用メモです。 「git gcってあんまし容量減らないよなぁ」 と思ったのが動機です。調べたけどパッと腑に落ちる記事がなかったので「自分で git のソースコード見た方がいいな」と急にモチベ発動してグワっと勉強しました。またついでに歴史改変の方法も調べたのですが、公式で既に WARNING が出てるほど非推奨化されてるfilter-branchを使用してる記事が多かったので、2021 年現在で多分一番推奨されてるfilter-repoを使ってやる方法もまとめました。 ちなみに容量減らしても高速化するかというとそこまで単純ではないです。そもそも減らさなくても partial clone で blob オブジェクトを必要最低限に指定して昔の blob をデフォルトで持ってこないようにしたり(--no-checkoutと併用するとより効果有る)、その後本当に自分が必要なやつだけ sparse-
ニッチな話題ですが、業務におけるCI/CDの現場では避けることのできない大規模リポジトリと戦うためのgit cloneのテクニックを紹介します。 この記事はDeNA Advent Calendar 2020の10日目の記事です。 CI/CDマニアの@Kesin11です。SWETではCI/CDチームの一員として、CI/CDの啓蒙活動やJenkinsを必要とするチームのサポートなどの業務を行っています。 はじめに おそらくどこの会社でも1つぐらいは巨大なリポジトリが存在しているかと思いますが、歴史あるリポジトリはgit cloneするだけで数分を要し、checkout後のリポジトリサイズがGB単位になることも珍しくないでしょう。業務で古くから存在するプロジェクトのリポジトリを触ったことがある方はきっと経験があるかと思います。 git cloneを実行するのは最初のセットアップ時だけなのであまり
Git scraping: track changes over time by scraping to a Git repository 9th October 2020 Git scraping is the name I’ve given a scraping technique that I’ve been experimenting with for a few years now. It’s really effective, and more people should use it. Update 5th March 2021: I presented a version of this post as a five minute lightning talk at NICAR 2021, which includes a live coding demo of build
Latest topics > GitHubに多数ある自分のリポジトリのデフォルトブランチをmasterからtrunkに切り替えた 宣伝。日経LinuxにてLinuxの基礎？を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能！ « ポジショントークに騙されないようにしたいし、狭い視野でポジショントークじみた極論を言うよりも、メリットとデメリット両方を把握した上でソフトランディングを図っていきたい Main Chromiumのコミットメッセージの「よりinclusiveにする」とはどういう意味か、GitHubがしている事の何がキナ臭いのか » GitHubに多数ある自分のリポジトリのデフォルトブランチをmasterからtrunkに切り替えた - Jun 12, 2020 Gitのデフォルトブランチ名
分散型バージョン管理システム「Git」に深刻な脆弱性が含まれていることがわかった。アップデートがリリースされている。 同システムの「credential helper」において改行を含む細工したURLを用いることで、Gitクライアントより認証情報を任意のホストに送信させることが可能となる脆弱性「CVE-2020-5260」が明らかとなったもの。 米国立標準技術研究所（NIST）の脆弱性データベース「NVD」による共通脆弱性評価システム「CVSSv3.1」のベーススコアは「9.3」で「クリティカル（Critical）」とレーティングされている。 脆弱性の判明を受けて、開発チームでは脆弱性へ対処した「同2.26.1」「同2.25.3」「同2.24.2」「同2.23.2」「同2.22.3」「同2.21.2」「同2.20.3」「同2.19.4」「同2.18.3」「同2.17.4」をリリース。また脆
GitHubでプルリクエスト前提の開発をしていると、git blameで「なぜ、このコードがこうなっているのか」調べる際に、commit idではなくプルリクエストの番号を表示してほしくなります。 というわけで書いたのが git-blame-pr.pl。 以下のような感じで表示されるので、調査がはかどります。 $ git-blame-pr.pl lib/core/request.c (中略) PR #446 PR #606 h2o_iovec_t h2o_get_redirect_method(h2o_iovec_t method, int status) PR #606 { PR #606 if (h2o_memis(method.base, method.len, H2O_STRLIT("POST")) && !(status == 307 || status == 308)) PR
どうも！大阪オフィスの西村祐二です。 バグを修正したり、機能を追加したりなど日々開発してリリース作業をしていると「CHANGELOG.md」を自動生成、自動更新したり、セマンティックバージョニングでタグを生成する仕組みがほしくなってきました。 いろいろ調べていると「ngx-semantic-version」がコマンド一発で「CHANGELOG.md」の自動生成環境を作ってくれて便利だったので紹介したいと思います。 「ngx-semantic-version」とは リリース作業時によくやるCHANGELOG.mdの更新や、Gitタグを付与する作業などを自動化する環境を構築してくれるライブラリです。 「ngx-semantic-version」を使うと下記のライブラリをいい感じにインストールして環境を作ってくれます。 commitlint Gitのコミットメッセージを規約に従ってるかチェックす
オンライン診療とは、自宅にいながら医師に直接毎日のスキンケアを相談したり、医薬品や漢方薬の処方を受けることができたりする診察のこと。お薬が処方された場合は郵送で薬局等にお薬を取りにいかなくても、自宅に届けられます。 普段、病院では発生する診察費用や処方箋費用はもちろん、お薬代以外の費用は一切かかりません。
git log -p や git diff などで差分を見るとき、行単位での追加/削除は表示されるが、行の中のどこが変わったのかは表示してくれない。例えば行の中の一単語を書き換えただけで、しかもその行が長い場合、どこに差分があるのか目で探すのが結構大変だった。 しかし先日、 diff-highlight という便利なモジュールが提供されていることを知り、早速導入してみた。 diff-highlightとは github.com gitコマンドの、行単位での差分を探す動作のポストプロセスとして実行され、同じ行の中の差分をハイライトしてくれる。 例えば、行の一部分だけ変えたときの git diff は、今までこんな感じだった。 それがこうなる。差分がわかりやすい。 diff-highlightの設定 この機能は gitコマンドに同梱されているため、インストールは不要。設定作業のみで使える。 ま
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Lefthook: Knock your team's code back into shape — Martian Chronicles, Evil Martians’ team blog 原文公開日: 2019/07/30 著者: Abroskin Alexander、Andy Barnov サイト: Evil Martians -- ニューヨークやロシアを中心に拠点を構えるRuby on Rails開発会社です。良質のブログ記事を多数公開し、多くのgemのスポンサーでもあります。 ※日本語タイトルは内容に即したものにしました。画像は元記事からの引用です。 以下は続編記事です。 参考: Lefthook: refactoring the Git Hooks automation tool back into shape—Mar
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
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
