So You Think You Know Git - FOSDEM 2024
Scott Chacon's FOSDEM 2024 talk on Git Tips and Tricks. Scott talks about: 00:00 - Introduction 01:06 - About Me (well, Scott Chacon) 02:36 - How Well Do You Know Git? 05:09 - Our Agenda 06:25 - Some Helpful Config Stuff 09:42 - Oldies But Goodies 16:22 - Some New Stuff (You May Not Have Noticed) 23:48 - Some Big Repo Stuff / Monorepo Stuff 33:29 - Some New Github Stuff 35:54 - GitButler 36:50 -
より良い Git コミットメッセージを書こう - Qiita
より良いコミットメッセージを残すことは 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://
Gitを置き換えるバージョン管理システム「Jujutsu」 | ソフトアンテナ
今やバージョン管理ツールとして圧倒的な人気を集める「Git」ですが、Linuxカーネル開発のために作られたという経緯もあり、使いこなすにはかりの経験値が必要となります。 この問題を解決するために、Googleのソフトウェアエンジニアによって、新しいバージョン管理システム「Jujutsu」の開発が進められています。 Jujutsuの素晴らしさを紹介する記事「jj init 」によると、Jujutsuは過去のバージョン管理システムの問題点やメリットを分析して作られていて、Googleの既存のバージョン管理システムを置き換える勢いがあるとのこと。 JujutsuはmacOSでは、brew install jjを実行するだけで使用することができ、バックエンドとしてGitを使用しているため、採用にコストがかからないというメリットもあるそうです。 公式サイトでは、Jujutsuの特徴がリストアップされ
git blameで「あ～、もっと過去があるじゃん、そこまでさかのぼってよ～」というときのtips - Qiita
履歴が複雑になっているケースでは(過去にgit mvを何度もやったとか、svnからgitにプロジェクトを移管したとか) git blameしたときに、いちばん初めのコミットまでさかのぼって表示してくれない場合があります。 もっとさかのぼってYO!! そんなときにgit blameをもっとさかのぼって見る方法。 結論 git blame （コミットハッシュ値） -- (ファイル名） これで任意のリビジョンを起点にして、そこから過去をみることができます。 詳細 まず、普通にgit blameします。 git blame hoge/file.php ここで見れた一番古そうなコミットハッシュ値(仮にbadcafeとします)をメモします。 メモしたら、その１個前を起点にして過去にさかのぼります。 git blame badcafe^ -- hoge/file.php これでも途中までしかさかのぼれな
Lazygit Turns 5: Musings on Git, TUIs, and Open Source
Lazygit Turns 5: Musings on Git, TUIs, and Open Source This post is brought to you by my sponsors. If you would like to support me, consider becoming a sponsor Lazygit, the world’s coolest terminal UI for git, was released to the world on August 5 2018, five years ago today. I say released but I really mean discovered, because I had taken a few stabs at publicising it in the weeks prior which fell
あるレポジトリのサブディレクトリ配下を別のレポジトリへ履歴付きで移行する - $shibayu36->blog;
Gitで開発していて、あるサブディレクトリ以下を別のレポジトリに移行したいと思うことがある。今回はそういうことをしてみたのでメモ。 まずGitHubにそのようなやり方の指南がある（Splitting a subfolder out into a new repository - GitHub Docs）。大体これで良いのだけれど、このやり方だとサブディレクトリのpathがそのままになってしまうという問題がある。大抵のケースで、あるサブディレクトリを別のレポジトリに分割したいとなった時、そのサブディレクトリがレポジトリルートに来てほしい。 そういう場合はGit Filter Repo — Splitting a Subfolder Into A New Repository | by Edward Ezekiel | Mediumにも紹介されているようにgit filter-repo --s
医療系スタートアップのバックエンドをモノレポ化した話 〜技術編〜 - 株式会社ヘンリー エンジニアブログ
こんにちは、ヘンリーの SRE の戸田と Wildcard Engineer の岩永です。 弊社ではレセコン一体型クラウド電子カルテの Henry を開発・提供しています。 前編の Henry のバックエンドをモノレポ化した戦略やプロセスに続いて、後編のこちらの記事ではモノレポ化の技術的手法を解説します。 dev.henry.jp 実際のモノレポ化の流れに沿って、ポイントを3点説明します。 2つの git リポジトリのマージ アプリケーション・ワークフローのモノレポ対応 モノレポへの切り替え当日に向けた手順書の作成 1. 2つの git リポジトリのマージ 今回のモノレポ化においては、もともと存在していた henry-general-api と henry-receipt-api という2つのマイクロサービスのリポジトリを、1つのリポジトリにマージし、それぞれのマイクロサービスがサブディレ
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 で shallow clone - Qiita
$ time git clone --depth=1 git@github.com:ruby/ruby.git 1.26s user 1.42s system 20% cpu 12.964 total 早い！ git log で見た時に commit log が depth で指定した数だけになっている。ローカルへの commit log をそれだけしか積まないので早くなるのだ。svn 的だ。 注意：ただし、このレポジトリから push はできなくなるので、用途は限定的だ。手元に素早く持ってきたいだけの場合に使う。Jenkins とか CI 環境で使うとよさそう。 branch あとこれはおまけだけど、clone してから git checkout -b ブランチ名 origin/ブランチ名 で branch を切り替えるよりも、clone 時に --branch でブランチ名を指定しつつ
git リポジトリの最新の履歴だけを取得する shallow clone - Qiita
git でリポジトリを clone した場合、通常は元のリポジトリを丸ごと取得してきます。 しかし、最新版が取得できればそれでよい、過去の履歴情報はいらない、という場合もあるかと思います。そんなとき、次のようにすればリポジトリを丸ごと取得せず、最新版だけ取得できます。 これは、git のマニュアルでは shallow clone と呼ばれています。 オプション depth に渡す値は、取得する履歴の数です。上記では 1 を指定しているので、最新のみを取得します。depth 1 で shallow clone したリポジトリで git log を実行すると、ログが 1 つしかないのが分かります。 利点 変更履歴が多くて通常の clone では時間がかかるような git リポジトリの場合、shallow clone を使うことで通常の clone より速く最新版を取得できます。 とりあえず最近
Conventional Commits
Conventional Commits A specification for adding human and machine readable meaning to commit messages Conventional Commits 1.0.0 Summary The Conventional Commits specification is a lightweight convention on top of commit messages. It provides an easy set of rules for creating an explicit commit history; which makes it easier to write automated tools on top of. This convention dovetails with SemVer
GitHub上にあるリポジトリに対してAPIを通じてgit grepライクに走査できるツール gh-grep (gh grep) を作った - Copy/Cut/Paste/Hatena
git grep 便利ですよね。 私は git grep と git gsub は本当によく使います。 ところで git grep はローカルリポジトリがないと実行できません。 ローカルにリポジトリがなければ git clone して、 git grep すればいいのですが、もう少し簡単にgrepするために gh-grep を作りました。 github.com gh-grep gh-grepはGitHub APIを使ってGitHub上のリポジトリに対してgrepをするツールです。 特徴は、全てGitHub APIを通じて実行するためローカルに git clone することなくgrepできることです。 また、APIを使っている特徴を活用して複数リポジトリに対してgrepすることなども可能になっています。 あと実行が遅いです。ひたすらGitHub APIを叩いているので...*1。 インストー
Top Visual Studio Code Git Extensions in 2021
I know that some of you reading these lines already hate me. Some of you could and actually spend every working hour in front of a terminal window; you love it. There is nothing wrong with it, and some Command Line Interface (CLI) tools are so well designed that even if you had a graphical user interface, you would most probably never use it. I hear you! I actually love working inside a terminal w
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - jesseduffield/lazygit: simple terminal UI for git commands
GitHub - extrawurst/gitui: Blazing 💥 fast terminal-ui for git written in rust 🦀
GitHub - newren/git-filter-repo: Quickly rewrite git repository history (filter-branch replacement)
GitHub の基礎 - 管理の基本と製品の機能。 - Training
Git でのバージョン コントロールの概要 - Training
コミットメッセージ規約 「Conventional Commits」を導入してみよう！ / Let's use Conventional Commits
Sourcegraph
