エムスリー Advent Calendar 2025 4 日目の記事です。 クラウド型電子カルテのデジカル開発チームで色々なことをやっている井上 (@wtr_in) です。一年を通して伊藤園の天然ミネラル麦茶を愛飲していますが、最近どうも味が変わった気がしています。（しませんか？） さて、すでに当ブログでも過去に何人か記事を書いていますが、弊社では GitLab Server から GitHub Enterprise Cloud への移行を進めています。 www.m3tech.blog デジカルチームでもリポジトリごとに順次移行を進めていますが、その際に GitHub Actions を使って Pull Request のマージ方式を間違えないための仕組みを作ったので、その内容を紹介します。 先に3行でまとめ 抱えていた課題 前提: PR を Squash マージしたい そして生まれる人間
はじめに Claude Code 使ってますか？ターミナルから Claude に直接コーディングタスクを投げられる便利なツールなんですが、デフォルト設定のまま使うのはちょっともったいない。というかいちいちいろんなことを聞いてきてめちゃくちゃダルい。 syu-m-5151.hatenablog.com settings.json をちゃんと設定すると、セキュリティも保ちつつ、もっと快適に使えるようになります。全体的に疲れている時の~/.claude/settings.json と~/.claude/CLAUDE.md · GitHub 私のデフォルトの設定も公開してますのでよかったら参考にしてください。 ここで読むのをやめる人のために言っておくと Claude Codeの設定は優先順位があるので覚えておくと良い です。あと、比較的に今は黎明期なので非推奨や追加機能が多いのでその点も注意が必要
2024.09.27 OpenAI APIを使ってgit commitメッセージやコードレビューをAIに任せましょう！ 次世代システム研究室の Y.I です。 OpenAI API を活用してちょっと便利なコマンドを作成したのでご紹介します。作成したものは、「自動Git Commitメッセージ生成」と「コードレビュー」機能です。LangChainやVectorDBなどを利用しなくても、発想次第で便利な機能を作れますので1例としてご覧ください。 機能紹介 Pythonで以下の機能を実現しています。 Git commitメッセージの自動生成 Gitの変更履歴に基づき、適切な日本語のcommitメッセージを生成します。 コードレビューの自動化 Gitの変更履歴に基づき、コードに問題がないかやパフォーマンス改善の提案を行います。 openai apiのtokenを環境変数から取り込み 簡易的ですが
今やバージョン管理ツールとして圧倒的な人気を集める「Git」ですが、Linuxカーネル開発のために作られたという経緯もあり、使いこなすにはかりの経験値が必要となります。 この問題を解決するために、Googleのソフトウェアエンジニアによって、新しいバージョン管理システム「Jujutsu」の開発が進められています。 Jujutsuの素晴らしさを紹介する記事「jj init 」によると、Jujutsuは過去のバージョン管理システムの問題点やメリットを分析して作られていて、Googleの既存のバージョン管理システムを置き換える勢いがあるとのこと。 JujutsuはmacOSでは、brew install jjを実行するだけで使用することができ、バックエンドとしてGitを使用しているため、採用にコストがかからないというメリットもあるそうです。 公式サイトでは、Jujutsuの特徴がリストアップされ
背景 GithubのプルリクやGitlabのMerge Requestを書くのって正直面倒ですよね。AIにやってもらいましょう。AWS BedrockのClaude2であればトークン長が100kらしいので大きめの入力もできるのが嬉しいですね。ChatGPTだと少し大きくなるとすぐに溢れちゃって実用的ではなかったのですが、こちらはいけそうな雰囲気。とりあえずやってみました。 ソースコード 以下はPythonで記述されたスクリプトです。このスクリプトはGitの差分（diff）を取得し、それをClaude2に送ります。Claude2はその差分から変更点をまとめ、標準出力として返します。 import json import sys import boto3 def request_to_claude2(prompt: str): client = boto3.client("bedrock-ru
ずっとgit logの内容を検索するときに-Sオプションを使っていたが、実は近いオプションに-Gオプションもあり、探したい内容によっては使い分けないとダメということを初めて知った... 詳しくはhttps://git-scm.com/docs/git-logの-Sと-Gのドキュメントを見てほしい。簡単にまとめると -Sは指定した文字列の出現回数が変わるdiffがあるcommitを検索する -Gは指定した正規表現がマッチする文字列がdiffにあるcommitを検索する ドキュメントの事例部分が結構わかりやすくて、以下のようなdiffがあった場合 + return frotz(nitfol, two->ptr, 1, 0); ... - hit = frotz(nitfol, mf2.ptr, 1, 0); -S frotzで検索をかけると、frontsの出現回数は変わってないのでマッチしない
「Gitのコミットメッセージをしっかり書こう」という記事を読んで、いい話だなーと思う一方で、うちのチームはちょっと前に「コミットメッセージは適当でいこう」って決めたなーって思った。 Gitのコミットメッセージをしっかり書こうという話【備忘録的共有】 | SIOS Tech. Lab しっかり書くのを否定するわけでは全然ない。しっかり書くのはしっかり書くのでいいなって思う。どっちがいいかはチームやプロダクトによるので、チームがいいと思う方を選べばいいかなと。 僕もしっかり書くほうがいいなって思うときもあるのだけど、今のチームでは適当のほうがいいなってだけ。 しっかり書きたいとき 僕が、コミットメッセージをしっかり書きたいときはどういうときだろう？って考えると、OSSにプルリクエストを出すときかなぁ。自分は特にOSSの何かを作ってるわけじゃないけど、自分で何かのOSSを作るならある程度ちゃんと
(訳注：2015/10/31、いただいた翻訳フィードバックを元に記事を修正いたしました。) (訳注：2015/11/1、いただいた翻訳フィードバックを元に記事を再修正いたしました。) 訳： プロジェクトが長引くほど、私のGitのコミットメッセージは情報が薄くなっていく。 イントロダクション | 7つのルール | ヒント イントロダクション：なぜ良いコミットメッセージを書くことが重要か Gitのリボジトリのログをランダムに閲覧すると、ひどいコミットメッセージを目にすることがあります。例として、私が昔書いたSpringにコミットした これらのgem を見てみましょう。 $ git log --oneline -5 --author cbeams --before "Fri Mar 26 2009" e5f4b49 Re-adding ConfigurationPostProcessorTest
When I enter a command: git tag -l I get such results: rc-0.9.0.0 rc-0.9.0.1 rc-0.9.0.10 rc-0.9.0.11 rc-0.9.0.12 rc-0.9.0.2 rc-0.9.0.3 rc-0.9.0.4 rc-0.9.0.5 rc-0.9.0.6 rc-0.9.0.7 rc-0.9.0.8 rc-0.9.0.9 Instead of this I want: rc-0.9.0.0 rc-0.9.0.1 rc-0.9.0.2 rc-0.9.0.3 rc-0.9.0.4 rc-0.9.0.5 rc-0.9.0.6 rc-0.9.0.7 rc-0.9.0.8 rc-0.9.0.9 rc-0.9.0.10 rc-0.9.0.11 rc-0.9.0.12 How it's possible to sort cur
Subversion vs Github 青い線と赤い線。 あなたの会社は、どちらと運命をともにしたいでしょうか？ 業界誌でも大きく特集されている 「Githubは世界標準の開発環境である（ｷﾘｯ」by @HIROCASTER さん Githubを導入している先進企業たち 公開されている情報をもとにリストアップしてみました。 ご要望があれば追加します！ (Piece of Cakeさんを追加しました。） (サイボウズさんを追加しました。） これらの事例の中から資料をキリハリして、上司の説得に使いましょう。 ＼（サイボウズ）／ ＼（ペイパーボーイ）／ 技術的なアプローチを強化しようと、エンジニアのトップであるmizzyに 直属になってもらい、全社的に取り組むべき課題とチャレンジしたいことの洗い出しや 技術のアウトプットを高めるための取り組みを始めました。 [中略] そのような取組の結果、エン
会社でbundle installやgit cloneしたときに git clone git://github.com/creationix/nvm.git ~/nvm Initialized empty Git repository in /home/xxxx/nvm/.git/ github.com[0: 207.97.227.239]: errno=Connection timed out fatal: unable to connect a socket (Connection timed out) GitHub Connection Timed Out みたいなのが出ました。 git cloneだとプロトコル変えればいいんだけど、 bundlerだとGemfileを修正するのはちょっと面倒。 gitプロトコル(9418)をfirewall開けて欲しいけど、 手続き面倒なのでなんか
目次 はじめに Git を使ったことがない方へ 生のデータが見たい方へ Git の全体像 .git の中身 Git オブジェクトデータベース 4種類のオブジェクト リファレンス リファレンスのリファレンス 大きなツリー Git オブジェクトの ID と 中身 ハッシュ関数 SHA1 の簡単な説明 tree と blob オブジェクト tree と blob の参照関係 ルートツリーの ID でツリー全体を識別する commit オブジェクト リファレンスとブランチ ブランチ ブランチ先頭を指すリファレンス HEAD リファレンス detached HEAD 2種類のタグ 一時待避 (stash) インデックス キャッシュとしての役割 マージ Fast-Forward マージ non Fast-Forward マージ rebase reset 2種類のブランチ 各リポジトリが自分のブランチを
差分の確認に meld を使う Git での diff に meld を使うにはどうするのか検索してみると、次の２つの方法がありました。 wmanley/git-meld - GitHub How to: Meld for Git diffs in Ubuntu Hardy - Nathan Hoad "git diff ブランチ1..ブランチ2" したいといった用途だと、1 は diff をいっぺんに表示する "meld dir1 dir2" 的な挙動です。2 は 対になる 1 ファイル diff を表示するだけの meld がまず起動し、その meld を閉じると次の差異のあるファイル同士の diff を表示する meld が立ち上がる、といった挙動です。1 の git-meld の方が使いやすかったです。 ▼ 1 の設定 [alias] ... meld = /home/m/Drop
この記事は会社内の別チームの方に、 僕の今のチームで git をどう運用してるかを ワークショップ形式で説明するための資料である。 事前準備 git と git-flow を入れておくこと 参考資料(Macでgitとgit-flowインストール) - xcode cli toolインストール -- https://daw.apple.com/cgi-bin/WebObjects/DSAuthWeb.woa/wa/login?appIdKey=d4f7d769c2abecc664d0dadfed6a67f943442b5e9c87524d4587a95773750cea&path=%2F%2Fdownloads%2Findex.action - homebrew のインストール -- https://github.com/mxcl/homebrew/wiki/installation - b
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
