こちらはエムスリーAdvent Calendar 2024 13日目の記事です。 こんにちは、エムスリーエンジニアリンググループの福林 (@fukubaya) です。 今回は、長年運用されてきたレポジトリをgitを使って発掘する上で使っている道具を紹介します。 福岡タワー（ふくおかタワー）は、福岡県福岡市早良区のシーサイドももち地区にあるランドマークタワー（電波塔）。本文には関係ありません。 帳票環境 レポジトリからDBテーブルの使用箇所を探す スケジュール設定だけ消される gitレポジトリ考古学 ファイルが消えたコミットを知りたい ある記述が消えた(追加された)コミットを知りたい あるテーブルが使われているバッチを探したい 大量にgit grepしたい git grepの結果がEUC-JPでもUTF-8でも正しく日本語を出力する まとめ We are hiring! 帳票環境 弊社には「
This is a port of Facebook's hg absorb, which I first read about on mozilla.dev.version-control: Facebook demoed hg absorb which is probably the coolest workflow enhancement I've seen to version control in years. Essentially, when your working directory has uncommitted changes on top of draft changesets, you can run hg absorb and the uncommitted modifications are automagically folded ("absorbed")
今まで id:mizdra はターミナルで Git ブランチを切り替えるときに、zsh + peco を使った Git ブランチ検索用のキーバインドを使用していた。 # .zshrc function select-git-branch() { selected_branch=$(git branch | cut -c 3- | peco) BUFFER="${LBUFFER}${selected_branch}${RBUFFER}" CURSOR=$#LBUFFER+$#selected_branch zle redisplay } zle -N select-git-branch bindkey '^b' select-git-branch zsh + peco で Git ブランチを切り替える様子 便利っちゃ便利なのだけど...沢山のブランチの中から「あの時作業していたあのブランチ」
ドリ山田金之助がCursorというAI搭載テキストエディターを使って独自のビデオ編集をやってるという話を風の噂で聞いた。 ドリ山田くーん、遅い、遅いよー とか煽るのも可哀想だったので放置していたのだが、昨日(!!)もっとゴイスーなAIソフト開発環境を触って元に戻れなくなってしまったのでご紹介しておく。 その最新の開発環境とは、人呼んでAIder(エイダー) こいつの何がすごいかというと、gitをcloneしてくると、ソースコード読ませて「これにこういう機能を追加しろ」と言うと勝手に追加してgit commitしてしまう。良きところで/git push origin mainとやればやってくれる。 まあAI開発ものにありがちな、「自信満々で提出されたけどいざ動かすとポンコツ」なケースが多くて、使うには忍耐が必要だが、頭は使わなくていい。たまに頭を使ったふりをして「もしかしてこの関数がやばいん
はじめに こんにちは、kenです。みなさんコンフリクト解消してますか！ チーム開発をしているとコンフリクトとは嫌でも向き合うことになりますが、コンフリクト解消って緊張感のある作業なのでやりたくないですよね。 そんなコンフリクト解消をちょっぴり楽にする(かもしれない)コマンドを最近知ったので今回はそれを紹介します、その名もgit rerereです。 git rerereとは Gitの公式ドキュメント（日本語版）には次のように記載されています。 git rerere コマンドはベールに包まれた機能といってもいいでしょう。これは “reuse recorded resolution” の略です。その名が示すとおり、このコマンドは、コンフリクトがどのように解消されたかを記録してくれます。 そして、同じコンフリクトに次に出くわしたときに、自動で解消してくれるのです。 ここに書かれているように、git
GitHub CopilotにはCLIがあるのを思い出して、コマンドの実行結果をそのままプロンプトに渡すと、文脈に沿った仕事をお願いしやすいんじゃないか、と思って、試してみた。 git stashをよく使うのだけど、一覧になっていると、何がstashされているかわからないので、stashの保存時に、内容を要約してもらう、というタスクを試してみる。 なんらかのCLIにdry-run機能をつけている途中で、git stashしたいとする。 index f1f5a2f..dd70bf5 100755 --- a/cli.js +++ b/cli.js @@ -19,6 +19,10 @@ command } else { command.help(); } + }) + .arguments(['dry-run']) + .action(async(file) => { + console.lo
今回の記事の内容は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-replay というコマンドが追加されたみたいなので触ってみた。とは言っても、自分はあんまり凝ったことはやらないので、細かいところまでは踏み込まずに最低限の使い方ができたらいいなってくらいの気持ちで触った。 github.blog この記事には、こんな風に書いてある↓ git replay exists to address these challenges. It offers an alternative to git rebase that, in addition to being far more performant: Can operate in bare repositories. Can rebase branches other than the currently checked-out one (in non-bare repositories). Can
February 16, 2024 Hello! I always wish that command line tools came with data about how popular their various options are, like: “basically nobody uses this one” “80% of people use this, probably take a look” “this one has 6 possible values but people only really use these 2 in practice” So I asked about people’s favourite git config options on Mastodon: what are your favourite git config options
January 26, 2024 Hello! I posted a comic on Mastodon this week about what’s in the .git directory and someone requested a text version, so here it is. I added some extra notes too. First, here’s the image. It’s a ~15 word explanation of each part of your .git directory. You can git clone https://github.com/jvns/inside-git if you want to run all these examples yourself. Here’s a table of contents:
こんにちは！ブロックチェーンチームでエンジニアをしている id:dorapon2000 です。最近買ってよかったものは「潮の華 あおさといわしふりかけ」です。 今回は Git の Squash マージについての知見を共有したいと思います。端的に言うと、 チーム開発で Non Fast-Forward マージをやめて Squash マージを採用し、再び Non Fast-Forward マージに戻した経緯の説明です。Squash マージを運用に導入するか考えたことがある方の参考になればと思います。 Squash マージとは マージには 3 種類ありますね。みなさんはトピックブランチを main へマージする際にどのマージ方法を利用していますか？ Fast-Forward マージ git merge --ff-only Non Fast-Forward マージ git merge --no-f
git stashをもっと便利に扱いたいと思い、fzfを使って使いやすくしてみた。以下のURLに載っているものを参考にして自分にとって使いやすいように改変した。 fzfでGUI選択したファイルをgit stashするシェルスクリプト git-stash-explore できたこと 今の変更ファイルをfzfを使って選択して、選択したものだけをstash (git-stash-select) stash一覧の中から中身をpreviewしながら選び、apply or deleteする (git-stashes) 現在の変更ファイルから一部を選んでgit stashするコマンド fzfでGUI選択したファイルをgit stashするシェルスクリプト を参考に、git-stash-selectというコマンドを作った。 #!/usr/bin/env bash # Get the root direct
はじめに CHANGELOGを自動生成するツールは多種多様です。Conventional Commitsに対応したコミットメッセージから生成するもの、GitHub上でのリリースやタグ付けまで行うものなどがあります。 CHANGELOGを自動生成する際には、バージョンタグに対応したコミットメッセージを基にしてくれると便利です。コミットメッセージを適切に付けるだけで、後はツールにお任せできます。ただし、いくつかの懸念点が存在します。 懸念点 1: チキンエッグプロブレム CHANGELOG自動生成ツールは便利ですが、一つの大きな問題があります。それは、Gitのタグとコミットメッセージを基にCHANGELOGを生成するため、タグを作成する前にはCHANGELOGが存在しないという点です。この状況は「チキンエッグプロブレム」に類似しています。具体的には、新しいバージョン（卵）がリリースされる際には
moznion サーバーサイドエンジニア Seattle, Washington在住 10年モノのCoffeeScript on node というのは若干言いすぎで、およそ9年モノです 2014年当時の状況 ES2015以前 (そりゃそう) Babelはあった TypeScriptブレイク以前 (だいたい2016年くらいから広くproduction readyになったという印象) AltJSの萌芽 => この時点でCoffeeScriptを採用したのは間違いではないはず...... 2023年現在の状況 JavaScriptの言語機能がめちゃ拡張された TypeScriptがメジャーに DHH、TypeScriptをやめる => CoffeeScriptを使うメリットはおそらく失なわれたと言ってもよい (このへんを参考にした: https://yosuke-furukawa.hatenab
「Gitのコミットメッセージをしっかり書こう」という記事を読んで、いい話だなーと思う一方で、うちのチームはちょっと前に「コミットメッセージは適当でいこう」って決めたなーって思った。 Gitのコミットメッセージをしっかり書こうという話【備忘録的共有】 | SIOS Tech. Lab しっかり書くのを否定するわけでは全然ない。しっかり書くのはしっかり書くのでいいなって思う。どっちがいいかはチームやプロダクトによるので、チームがいいと思う方を選べばいいかなと。 僕もしっかり書くほうがいいなって思うときもあるのだけど、今のチームでは適当のほうがいいなってだけ。 しっかり書きたいとき 僕が、コミットメッセージをしっかり書きたいときはどういうときだろう？って考えると、OSSにプルリクエストを出すときかなぁ。自分は特にOSSの何かを作ってるわけじゃないけど、自分で何かのOSSを作るならある程度ちゃんと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
