これからは git restore を使ってみようかな - Mitsuyuki.Shiiba
Gitの基本的な使い方のおさらいをチームのLearning Sessionでやろうかなと思ってドキュメントを眺めてたら、あれ？こんなんあったっけ？と思うコマンドがあった。 git restore と git switch Git 2.23で導入されたみたい。去年の夏か。 https://github.blog/2019-08-16-highlights-from-git-2-23/ まだExperimentalみたいだけど、面白そうなので触ってみた。今日は git restore の話。git switch はまた気が向いたら。 https://git-scm.com/docs/git-restore ## リストアの前にWorking Treeとかの話をざっくり GitにはWorking TreeとStaging AreaとGit Directoryという3つの場所がある。 file.t
【セキュリティ ニュース】Gitに深刻な脆弱性、認証情報など取得されるおそれ（1ページ目 / 全1ページ）：Security NEXT
分散型バージョン管理システム「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」をリリース。また脆
Highlights from Git 2.19
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
Mergify — The Continuous Merge Platform
Save time and CI costs while making code merging more secure and less frustrating for developers.
サクラエディタ GitHub 移行 - clock-up-blog
概要 日本製 OSS のテキストエディタである サクラエディタ はずいぶんと前から SourceForge.net 上で Subversion 管理されている。 ずいぶんと長い間サービスを継続していただいている SourceForge に感謝の念は尽きない。が、今の時流としては SourceForge による Subversion 管理を続けるよりも、機会があれば GitHub 側に移行したほうが機能追加や修正等のプルリクエストを受け付けやすくなり、品質の向上に繋がるのでは、というのが自分の所感。 今回はコミュニティに対しては事後承認的な形で、サクラエディタ V2(UNICODE版) 部分のリポジトリを GitHub に移行してみる。 コミュニティの承認が得られれば今回の GitHub 移行を正式なものとみなし、更なる整備を進めたい。 移行結果（コミュニティの承認待ち） 移行元: http
git blameでプルリクエストの番号を表示する
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
コミットサブジェクト（題目）とメッセージ部分を分けるには - Qiita
本題 https://medium.com/@risacan/コミットメッセージの書き方-64aeadd92057 の[2行目に空行を設ける]の節をみて、意外と知らない人多いのかなぁ、と思ったので。 上のリンクでは、git commit打ってから、コミットログの編集画面に移行して、コミットメッセージをコミットサブジェクト（題目）とメッセージ部分に分けて書いているが、その時、2行目を空白にする必要があるという旨がかかれている。 これは、実はgit commitのmオプションを2つ重ねれば同じことができる。 つまり、git commit -m "short msg" -m "long description"を使えばよい。 どのように表示されるかは、上のリンクと参考を参照してください: 参考) https://saraford.net/2017/01/07/how-to-commit-an-o
Gitのステージング領域の正体を探る | メルカリエンジニアリング
ソフトウェアエンジニアの @DQNEO です。こんにちは。 Gitの内部構造を深掘りするシリーズ３回目です。 前回までのお話はこちら Gitのつくりかた – Mercari Engineering Blog Gitのコミットハッシュ値は何を元にどうやって生成されているのか – Mercari Engineering Blog 今日はみんなだいすき「ステージング領域」の中身について解説してみます。 ステージング領域とは何か？ 簡単に説明すると「次にコミットしたときにコンテンツとして登録されるもの」リストです。(別名「インデックス」ともいいます。) このリストは、 git addやgit rmしたときに書き換わります。 (古くはcacheと呼ばれていました。内部実装やgit diff --cachedに今もその名残があります。) git addのマニュアルに説明があります。 Git – git
Git 2.11 has been released
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
Git 2.10 has been released
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
gitにおけるコミットログ/メッセージ例文集100
私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。 要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。 仕方なく自分でまとめたので、増田に垂れ流しておく。 はじめにここで挙げているコミットログは全て実際のコミットログからの転載である。当然ながら各コミットログの著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユースの範囲なら許してくれるだろうと考え名前とプロジェクト名は割愛したが、ここ
git翻訳後記(1) - cherry-pick - おんがえしの blog
はじめに Git入門というgitのリファレンスマニュアルの日本語訳を載せている有名なページがありますが、最近ここで翻訳のお手伝いをさせてもらっています。 はじめはgitの勉強がしたくて、どうせやるなら少し位は人の役にたった方がいいだろう、位の軽い気持ちで始めたものですが、実際にやってみると本を読むだけではなかなか分からないことが分かったり、そもそも翻訳作業自体もGitHubを使って行われているため結果的に実践練習になったりと、思っていた以上に得るものが多いと感じています。またリファレンスマニュアルというものはどうして簡潔に書く必要があるため、そこには載らないけど有用だなーと思うことも調べたり聞いたりでちょこちょこ出てきます。 そこで、gitに関して役にたった、知って得した、といったことを、私自身の復習や文章を書く練習も兼ねて翻訳後記として少しずつ載せていこうと思います。 git-cherr
Git2.9のキレイなdiffを出すためのconfig - Qiita
Git 2.9 has been released https://github.com/blog/2188-git-2-9-has-been-released 昨日キレイなDIFFが出せるgit2.9がリリースされました。 homebrewで brew upgrade git な感じでアップグレードすれば2.9は入るのですが、 このキレイなDIFFは標準では有効になってないので、記事にあるとおりに設定を行いましょう。 だいたい以下のような感じのコマンドうてばいいと思います。 下準備：diff-highlightにPATHを通す まぁ通さずに直接読んでもいいんですが、通しておきましょう。 homebrewでいれるとdiff-highlightさんは↓あたりにいるのでPATHを通しておきましょう。 export PATH=$PATH:/usr/local/Cellar/git/2.9.0/s
git branch の結果を時間順にソート: git branch --sort=-authordate - Islands in the byte stream
id:kazuho さんと「gitのbranchを消すべきか否か」という話をしていて、ぼくの「ローカルにせよリモートにせよbranchが増えすぎると目的のブランチを見つけられない」という意見に対して次のエントリを教えてもらったのでした。 git branch の結果を時間順にソート - kazuhoのメモ置き場 一理あるかもしれないと思ってこれをgitに組み込むためにgitのソースコードを眺めていたら、実はもうできるということを知りました。それがこれ: # 新しいのが下 git branch --sort=authordate # 新しいのが上 git branch --sort=-authordate このソートに使えるフィールドは、 git branch --help を引くと "The keys supported are the same as those in git for-e
git bisect で問題箇所を特定する - Qiita
以前は問題なく動いていたはずの機能が、最新版では動かなくなっている・・・。こんなときは、「どのコミットが問題を混入させてしまったのだろうか？」を知りたくなるでしょう。 これを手助けするのが git bisect コマンドです。git bisect コマンドは、二分探索によって問題箇所を特定します。 事前準備 最初に大事なことがひとつあります。それは、「問題がない（good）状態と問題がある（bad）状態を、確実に判定できるようにする」 ことです。 当然のことではありますが、ここがあやふやだと、二分探索をしても問題箇所をうまく特定できません。 可能なら、「テストスクリプトを1つ実行するだけで判定」できるようにしたほうが良いです。このとき、テストスクリプトは、git リポジトリからチェックアウトした作業ツリーに対して実行できるようにします（例えばソースからのビルド処理もテストスクリプトに含めま
git blameによるSRP（単一責任原則）の定量化 - どこでも見れるメモ帳
はじめに ソースコードを静的解析することでSRP（単一責任原則）を定量的に算出します．*1 svn blameによるSRP算出*2を参考に、git blameによる算出をshで行ってみました． このSRP値が最大のモジュールが王様モジュールに相当します． # 単一責務性の違反指数（SRP） # SRP＝R＋U＋((L/100)－5) # R：修正リビジョンのユニーク数 # U：修正ユーザのユニーク数 # L：モジュールのライン数 function get_SRP() { local target_filepath=$1 echo $(( \ $(git --no-pager blame --line-porcelain $target_filepath | sed -n 's/^summary //p' | sort | uniq -c | sort -rn | wc -l) + \ $(
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Gitの認証情報を奪い取れるGit 2.26.0以下にある脆弱性について
GitHub - jesseduffield/lazygit: simple terminal UI for git commands
きれいなcommit, pull requestを知りたい/作りたい方のためのgit勉強会
SIOS Tech. Lab - エンジニアのためになる技術トピックス
