新しくプロジェクトに入った人がリポジトリの現状を素早く把握するためのGitコマンド5選
ITエンジニアのアリー・ピエホフスキー氏が、「全然知らないプロジェクトの現状を素早く把握できるGitコマンド」を5つ紹介しています。 The Git Commands I Run Before Reading Any Code https://piechowski.io/post/git-commands-before-reading-code/ ◆過去1年間で最も変更されたファイル20個 以下はファイル名を過去1年間の変更数の多い方から20個並べるコマンド。 git log --format=format: --name-only --since="1 year ago" | sort | uniq -c | sort -nr | head -20 変更頻度の高いファイルを確認することで「活発に開発されている部分」や「予測不可能な影響を広い範囲に与えてしまっている部分」を知ることができま
Claude Code デスクトップで Worktree を作成するとき .worktreeinclude で .gitignore で除外されているファイルを含める
Claude Code デスクトップ Claude Code のデスクトップ版で新しいセッションを開始するとき Worktree を作成するのは簡単です。セッションの作成画面で「Worktree」チェックボックスをオンにするだけです。 Claude Code によって作成された Worktree は git worktree list コマンドで確認できます。 $ git worktree list /Users/xxx/sandbox/kanban-app 449a11e [main] /Users/xxx/sandbox/kanban-app/.claude/worktrees/quirky-kare 449a11e [claude/quirky-kare] Worktree のフォルダを開くと、.env ファイルなど、.worktreeinclude に記述されたファイルがコピーされ
git-wtを導入した - koicの日記
git-wt を導入したので、メモとして導入ログを記しておく。 github.com 導入動機 導入ログ インストール 設定 導入動機 Agentic Coding によってにわかに脚光を浴びている git worktree だけれど、実際のところワークツリーディレクトリどこに置くの？といった話などちょっとした敷居がある。特に ghq ユーザーにとっては、ghq root (e.g, ~/src, ~/ghq) のディレクトリの直下にワークツリーを置くような運用だと、いかにも管理がしづらいのでどうするかという問題があった。 今回 songmu さんによる以下の神機能が入ったということで、個人的には git-wt が顧客が本当に求めていたものになったので導入することにした。 github.com 正直 ghq root 直下にリポジトリと並んでワークツリーディレクトリがあると、理由あってワー
コミットメッセージをClaudeに書かせるgit aicommit - Write and Run
そういうコマンドがあるわけではありません。 以下のような git alias を .gitconfig に設定すると git aicommit で Claude にコミットメッセージを書かせられるというだけです。 [alias] aicommit = "!f() { COMMITMSG=$(claude -p 'Generate ONLY a one-line Git commit message in English, using imperative mood, summarizing what was changed and why, based strictly on the contents of `git diff --cached`. Do not add explanation or a body. Output only the commit summary line.'
Gitの中身
はじめに Gitで管理するプロジェクトには.gitというディレクトリがあり、その中にGitの管理情報が入っている。その中には、全てのコミットや、いろんなバージョンのファイル、ブランチ、タグといった情報が格納されている。Gitを操作するにあたり、この中身がどうなっているかを理解する必要はないし、もし中身を覚えたとしても、操作方法は変わらないまま、内部実装だけ変更になる可能性もある。それでも、Gitの仕組み、特に様々な情報が.gitにどのように格納されているかを知っておくのは二つの理由から有用だと考える。 一つ目の理由は、「物が動く仕組み」を知っておくことが教養だからだ。車を運転するのに、アクセルを踏めば進み、ブレーキを踏めば止まり、ハンドルを回せば曲がることを知っていれば十分だ。しかし、シリンダーにガソリンが噴射され、ピストンで圧縮したところで点火し、爆発する力でピストンが押される、という直
【Git】リポジトリをコンパクトにする - MarkdownとBullet Journal
リポジトリのディスク容量を削減する 開発を何年も継続し続けるとリポジトリもそれなりの規模になる。エンジニアの心理としてはリポジトリを整理したくなるもので、５種類の方法を紹介する。 方法 過去へのアクセス 削減度 作業の手軽さ git-gc ◎ 50%～ ◎ partial-clone ◎ 90%～ ◯ shallow-clone ◯ 90%～ ◯ logic-compress ◯ 90%～ △ reborn ✕ 100% ◯ その１：git gcを用いる これは最も簡単でそれなりの効果が得られる手段だ。通常Gitはfileをsnapshotして全て保存しているが、git gcを発動するとバイナリfileに差分保存することでディスク容量を圧縮する。オプションを付ける事でさらに圧縮率を上げる事が可能。 programmingforever.hatenablog.com その２：クローンサイズを
gitレポジトリ考古学に使う道具 - エムスリーテックブログ
こちらはエムスリーAdvent Calendar 2024 13日目の記事です。 こんにちは、エムスリーエンジニアリンググループの福林 (@fukubaya) です。 今回は、長年運用されてきたレポジトリをgitを使って発掘する上で使っている道具を紹介します。 福岡タワー（ふくおかタワー）は、福岡県福岡市早良区のシーサイドももち地区にあるランドマークタワー（電波塔）。本文には関係ありません。 帳票環境 レポジトリからDBテーブルの使用箇所を探す スケジュール設定だけ消される gitレポジトリ考古学 ファイルが消えたコミットを知りたい ある記述が消えた(追加された)コミットを知りたい あるテーブルが使われているバッチを探したい 大量にgit grepしたい git grepの結果がEUC-JPでもUTF-8でも正しく日本語を出力する まとめ We are hiring! 帳票環境 弊社には「
【Git】同じコンフリクト解消を繰り返している人に教えたい「git rerere」 - Qiita
はじめに こんにちは、kenです。みなさんコンフリクト解消してますか！ チーム開発をしているとコンフリクトとは嫌でも向き合うことになりますが、コンフリクト解消って緊張感のある作業なのでやりたくないですよね。 そんなコンフリクト解消をちょっぴり楽にする(かもしれない)コマンドを最近知ったので今回はそれを紹介します、その名もgit rerereです。 git rerereとは Gitの公式ドキュメント（日本語版）には次のように記載されています。 git rerere コマンドはベールに包まれた機能といってもいいでしょう。これは “reuse recorded resolution” の略です。その名が示すとおり、このコマンドは、コンフリクトがどのように解消されたかを記録してくれます。 そして、同じコンフリクトに次に出くわしたときに、自動で解消してくれるのです。 ここに書かれているように、git
中級Git操作
今回の記事の内容はGitHub共同創業者のScott Chacon氏の「Pro Git」と同氏の今年の「So You Think You Know Git」（Gitがわかっているとでも思っているか？）発表をベースにしている。 コンフィグ ここでコンフィグにてデフォルトとして指定して損がないオプションをいくつか紹介します。 git rerere git rerereは"reuse recorded resolution"（記録ずみ解決方法を再利用）の略語になっている。 名の通りマージコンフリクトがどう解消されたかを記録し、次に同じようなコンフリクトが発生した際、同様の解決方法を自動的に適用するためのコマンドです。 また、基本的にデフォルトにしてもときに差し支えないため、ぜひgit config --global rerere.enabled trueを実行してみてください。 git main
【Git助っ人】.gitignoreに追加したのに、いつまで経っても出てくるアイツをgitの世から消し去る方法 - Qiita
gitってたまに難しい。毎日使っていればpullだのpushは既に親友同然、statusあたりは頼れる兄貴感覚。しかしちょっとイレギュラーなことを行おうとした場合、急にやつはつっかかってきたりする。やめて欲しい。 今回はタイトルにもある通り、一度インデックスにあげてしまったファイルを、.gitignoreに後から追加した場合に、なんか思った通りにいかない時の話。 事象 一度インデックスに挙げたり(要はgit add済)、コミットしたファイル(git commit済み)を、あとから.gitignoreに追加した時に、なかなか追跡対象から外れないことがある。 パスも間違っていないのになぜだーと叫ぶ私。 相も変わらずしれっと追跡対象にファイルを提示し続けるgit。 仁義なき戦いとは、きっとこういうことを言うのだろう。知らないけれど1。 原因 .gitignoreに追記した削除対象のファイルのキャ
【Git】「.git」の中をGitに管理させてみた - Qiita
はじめに Git Advent Calendar 2023 3日目の投稿です。よろしくおねがいします。 前々回、前回を通じて以下のコマンドが使えるようになったと思います。 git init git add git commit git branch git checkout git merge 内部でどんな動きがされてるか気になったので、今回は↑のコマンドを実行した時に.gitフォルダの中がどのように変化するか観察したいと思います。 やること 下の感じで進めていきます。 リポジトリ(A)を作成 ⬇ リポジトリ(A)の.git内でgit initして.gitを管理するリポジトリ(B)を作成 ⬇ リポジトリ(A)の方でGitのコマンドをいろいろ打ってリポジトリ(B)で差分を観察 Gitリポジトリを2つ使っているので、切り替えがわかりにくい箇所があると思いますがご容赦ください 準備 「git/s
Linus Torvalds 氏の理想の git 運用と GitHub
Note 本記事の内容は Linus 氏の発言が人を傷つける場合に筆者がそれを良しと考えるといった意図はございません 少し古い記事になるが、 Linus Torvalds 氏 の GitHub に対する苦言が記事になっていた。 LinuxカーネルにNTFSドライバーが追加、トーバルズ氏はGitHub経由のマージに苦言 - ZDNet Japan Linus 氏が GitHub について苦言を呈するのは今に始まったことではない（後述）が、 別に GitHub のすべてを否定しているわけではない。[1] では一体何が不満なのか。Linus 氏の理想とする git の開発フローを考察した上で、整理してみたい。 Linus 氏の理想 結論からいうと、 「意味あるコミットを作れ」「コミットを大事にしろ」 という思想が伺える。 では 「意味あるコミット」「大事にされたコミット」 とは何なのか。 筆者な
Git ブランチの表現も Mermaid がよい感じに表示してくれました
Zenn や GitHub の Markdown から利用できる Mermaid には「Git ブランチを表現する」機能があります。 その機能を利用してみたところよい感じだったので、記述方法やカスタマイズについてなどを記事にしてみます。 Git ブランチを表現するとは？ ドキュメントでブランチの説明などを読んでいると下記のような図(グラフ)を見かけるかと思います。 図 1-1 AA によるブランチのグラフ A---B---C---D develop \ E---F---G topicA \ H---I---J topicB Mermaid の Gitgraph Diagrams を利用することにより、このような感じで表示できるようになります。 図 1-2 Mermaid によるブランチのグラフ 基本的な使い方 Mermaid 用コードブロックの先頭で gitGraph を記述し、Git の
git statusが43秒かかっていたのを1秒に高速化する大規模Gitリポジトリの操作を高速化するためのscalarを紹介 | Act as Professional
Git 2.38がリリースされました。 このバージョンから大規模Gitリポジトリの操作を高速化するscalarが同梱されるようになりました。 今回はこのscalarによって、どれぐらいGitの操作が高速化されるのかを簡単に検証します。 結論から言うとgit statusが約43秒かかっていたのが約1秒で操作できるようになります。 Install Git 2.38 Git 2.38からscalarが同梱されましたので、各自の環境にあわせてInstallなりVersionUpなりをしてください。 $ git --version git version 2.38.0 Before 大規模Gitリポジトリとしてchromiumを利用しました。 普通にgit cloneしてきて、git statusを実施すると約37秒かかります。 ❯ time git status On branch main Y
個人的「便利だな」と思ったGitコマンド4選 - Qiita
存在を知った時や使ってみた時に「これけっこう便利だな」と思ったGitコマンド4つをまとめました。 git fetch -p -pを付けることで、削除されたリモートブランチのリモート追跡参照が削除されるようになります。 例えばリモートリポジトリでbranchAが削除されると、git fetch -pによりローカルリポジトリ上のorigin/branchAが削除されます。 ※ git fetch --pruneも同様です ※ git pull -p/--pruneでプルする際に行われるフェッチにも適用できます git log --oneline コミットハッシュが短縮され、コミットログが1行で表示されるようになります。 ※ git log --abbrev-commit --pretty=onelineも同様です 表示例: git logの場合 commit cmhash2commithash
GitLabの「1年放置された無料アカウントのプロジェクトを削除する計画」がすっぱ抜かれて炎上し即中止へ
2022年8月4日に、「GitリポジトリホスティングサービスのGitLabが、無料メンバーシップのユーザーが所有する1年間アクティブでないプロジェクトを自動的に削除することを計画している」と報じられ、インターネット上で反対する声が相次ぎました。これを受けて、GitLabは翌5日に長期的にアクティブではないプロジェクトを保存する方針を発表しました。 GitLab plans to delete dormant projects from free accounts • The Register https://www.theregister.com/2022/08/04/gitlab_data_retention_policy/ GitLab U-turns on deleting dormant projects after backlash • The Register https://
本の原稿のバージョン管理を始めて20年たちました - golden-luckyの日記
「本の編集ではテキスト原稿のバージョン管理しか勝たん」という信念を押し通してきて、そろそろ20年近くになりました。厳密には19年くらいだと思うので、タイトルは誇張です。 久しぶりに編集者にとってのバージョン管理に言及したくなったので書いてみました。 目次です。 なんで「テキスト原稿のバージョン管理」の話をしなくなったか 「誌面レイアウトしたPDFとか紙に赤字を入れる」で編集するのもう無理… そこでテキスト原稿のバージョン管理 具体的にどうすればいいのさ 前提からつらつら書いていたらやたらに長くなりそうだったので、全部捨てて書き直したのに、それでもそれなりに長くなってしまった。 最後の節に書いた「 「原稿の移り変わり」を管理するのではなく、「原稿にありうる無数の可能性」を管理する 」というヒントだけでも持ち帰ってもらえればうれしいです。 なんで「テキスト原稿のバージョン管理」の話をしなくなっ
git add の対話モード
すると、対話モードが開始されます。対話モードでは、git statusと似た「どのファイルがステージに追加されているか・されていないか」といった情報と、この対話モードで実行できるコマンドの一覧が表示されています。 ❯ git add -i staged unstaged path 1: unchanged +4/-0 Cargo.lock 2: +1/-0 nothing Cargo.toml *** Commands *** 1: status 2: update 3: revert 4: add untracked 5: patch 6: diff 7: quit 8: help What now> status は git status とほぼ同等の目的を達成できますが、ステージした変更が左側、ステージしていない変更が右側に表示されます。直感的ですね。 update は、実行後ファイ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Git/GitHub を使う上で知っておくと嬉しいかも Tips【サイボウズ新人研修2025】
「Git for Windows」のシェルが「bash 4.4」から「bash 5.1」へ ～Vista対応も終了／シェルスクリプトの互換性問題に注意
