Gitの中身
はじめに Gitで管理するプロジェクトには.gitというディレクトリがあり、その中にGitの管理情報が入っている。その中には、全てのコミットや、いろんなバージョンのファイル、ブランチ、タグといった情報が格納されている。Gitを操作するにあたり、この中身がどうなっているかを理解する必要はないし、もし中身を覚えたとしても、操作方法は変わらないまま、内部実装だけ変更になる可能性もある。それでも、Gitの仕組み、特に様々な情報が.gitにどのように格納されているかを知っておくのは二つの理由から有用だと考える。 一つ目の理由は、「物が動く仕組み」を知っておくことが教養だからだ。車を運転するのに、アクセルを踏めば進み、ブレーキを踏めば止まり、ハンドルを回せば曲がることを知っていれば十分だ。しかし、シリンダーにガソリンが噴射され、ピストンで圧縮したところで点火し、爆発する力でピストンが押される、という直
日本のイチゴが大ヒット、アメリカで脚光の200億円調達ベンチャー。「世界で一人勝ち」の理由 | Business Insider Japan
オイシイファーム（Oishii Farm）の共同創業者兼CEO・古賀大貴氏は、「植物工場は日本が勝つべくして勝てる領域」と断言する。撮影：湯田陽子日本のイチゴが、ニューヨークで旋風を巻き起こしている。 アメリカを代表するフレンチ界の巨匠、ダニエル・ブリュー氏のミシュラン二つ星レストラン「ダニエル」をはじめ、味に惚れた有名レストランのパティシエから注文が殺到。ソースや飾りといった素材の一部ではなく、デザートの“主役”として、加工せずそのまま提供している店がほとんどだという。 レストランだけではない。高級スーパー・ホールフーズをはじめとする100店舗以上のスーパーでも販売。店頭に並ぶそばから飛ぶように売れている。 食通をうならせるこのイチゴ、生産しているのは日本人CEO率いるオイシイファーム（Oishii Farm）だ。 2016年にアメリカで創業した同社は、畑やビニールハウスではなく屋内の「
貿易関係の増田が現状をまとめてくれてたので（anond:20260313174445）、自分はもう少し踏み込んで「今後50%くらいの確率で起こりうる最悪の展開」について書いてみる。電力・ガス関係の仕事をしている立場から。 先に言っておくと、これは「確実に起こる」話ではない。ただし「起こってもおかしくない」話だ。 ■前提の整理 まず数字の確認から。日本の電源構成のうちLNG火力は約3割。日本のLNG輸入における中東依存度（カタール＋UAE＋オマーン）は約11%。「なんだ、たった11%か」と思った人は少し待ってほしい。 問題は3つある。 1つ目。カタールは世界のLNG輸出の約20%を占めるメガサプライヤーだということ。カタールが止まると「日本のカタール依存5%」の問題ではなく、世界のLNGスポット市場全体が干上がる。3月2日にJKM（日韓向けLNG指標価格）が一時40%近く跳ねたのはそのため。
仕組みから理解するGit
📚 本書について【無料公開中】 Gitの内部の仕組みを徹底的に丁寧に解説する本です。 「Gitはいかにバージョンを管理しているのか？」 「コミットはスナップショットと聞いたことがあるものの、どういう意味？」 「操作時にエラー表示をネットの記事を参考に対応しているけれど、実はよく分かっていない...」 といった疑問をすべて解決する基礎力を身につけることができます。 Gitの仕組みを理解することで、普段使いのツールとしても、より効果的に利用できるようになるほか、データ構造やアルゴリズムの学習用途としても楽しめるような構成になっています。
はじめにTIG真野です。 秋のブログ週間2023 の3本目は、設計ドキュメントをGit管理して腐らせないようにがんばってみた話をします。 前段として6年前、「我々はいかにシステム開発におけるドキュメント腐る問題と戦えば良いのか」という記事を書いたのですが、その後の試行錯誤はどこにも残していないことに気づきました。普段のフューチャー技術ブログですとちょっと引け目を感じるテーマですが、秋の夜長を楽しむため読み物成分を多めに書くというテーマのこのブログリレーにピッタリな気がするため、この機会をお借りします。 ドキュメントも色々な種別があるかと思いますが、この記事では設計ドキュメントを指すことにします。設計ドキュメントは開発メンバーが参照するもので、ステークホルダーへの説明資料に引用して使うことはあれど、主目的は異なるという前提です。Design Docの場合もありますし、システム構成図、ERD、
春の入門祭り2024の2記事目です。 Gitは、出自としては1週間で作られたLinuxカーネルのための分散バージョン管理システムでした。当時のワークフローに合わせてパッチをテキスト化してメールに添付できるような機能だったりが備わっています。 一方で、現代のGitは、デファクトスタンダードなバージョン管理システムになりLinuxカーネル以外のアプリケーション開発で利用されています。分散バージョン管理ではあるものの、サーバー・クライアント型の使われ方をしていて、GitHubやGitLabを核にして、ローカルで作ったブランチをpushして、Pull Requestの形にして管理しています。少なくとも周りで見る限りでは、それ以外の使われ方の方が少なくなってきてます。そんなこんなで求められている使われ方が変わってきていて、それに合わせた機能がぼちぼち増えています。それを活用することで、ウェブ画面上で
「mise」ってすごい使いやすいんですよ。 miseとは GitHubリポジトリの説明書きに 「dev tools, env vars, task runner」 と書かれているrust製のcliツールです。 この記事ではmiseヘビーユーザーの私が推したい生産性の上がる機能を紹介するので、miseを初めて知った人も、知ってるけど使ってないって人も、ぜひ一読してみてください。 ちなみに最近話題になりやすいAIツールのcliパッケージなどもmiseで管理できたりします。 推したい機能はこれです！ ① タスクランナー（私が推したい機能No.1） 私はmiseにおいてはタスクランナーが一番便利な機能だと思っているので最初に紹介します。 タスクランナーはmise.tomlによく使うスクリプトをタスクとして定義しておいて、mise runコマンドで実行する機能です。 ※設定ファイルはグローバルで有効
ヘリウム途絶、在庫切れへの秒読み
国際カタールのヘリウム生産が止まって3週間。本誌が13日付で「供給網の新たな死角」として報じたこの問題は、追加攻撃で局面が変わった。カタールエナジーはLNG（液化天然ガス）生産能力の17％が失われ復旧に数年を要すると発表。ヘリウムのスポット価格は倍増し、長期契約を持たない調達先から在庫が尽き始める時期が近づいている。このヘリウム発の素材ショックを起点に、海上運賃は3週連続で上昇し大手船社が緊急燃料割増に踏み切った。WTO（世界貿易機関）は19日に2026年の物品貿易成長率を1.9％に下方修正し、需要の土台も縮んでいる。ヘリウムが供給の上流を詰まらせ、運賃がコストを押し上げ、貿易減速が需要を削る。3つは並列ではなく、上流から下流へつながっている。（編集長・赤澤裕介） カタールのラスラファン工業都市は2日のイラン無人機攻撃で操業を停止し、4日にフォースマジュール（不可抗力）条項を発動した。本誌
追記 先日外部向けに、この記事の内容に追加補足などを加えて発表しました。動画のアーカイブ、資料も公開しましたので、もし動画の方がわかりやすい方はこちらをオススメします。 注意: 動画の質疑の中で、 github のリリース機能が、アノテートタグを使っていると明言してしまいましたが、間違いです。gitのデータ上はただの軽量タグで、 release の内容は軽量タグに紐づく形で、 github のアプリケーション上で管理されているはずです。 はじめに 調べてもう1年放置していた内容なんですが、アドベントカレンダーで重い腰を上げました。 Gitの内部の仕組みを知りたい（動機） 毎日使うといってもいいGitですが、どうやって履歴を管理してるんだとか、よくわからないまま使っているのが急に怖くなりました。 Gitを触り始めで、よく以下のような疑問が沸くと思います。 どうやってGitは履歴を管理してるん
対象読者 Gitをより深く理解したい方 Gitの自作に興味がある方 Gitの内部構造を学ぶ意義 Gitの使い方を知っている人でも、それぞれのサブコマンドが実際どういった挙動をしているか、ましてや内部構造がどうなっているかを学んだことがある人は少ないかもしれません。というのも、Gitが内部を知らなくとも十分使える優秀なツールになっているからだと思います。 しかし、Gitの内部実装を知ることで、コマンドの挙動を正確に理解できるだけでなく、Gitを使っていて何らかの問題が起きたときにも、自分で対処できるようになります。そうしたGitの地力を鍛えるために、内部構造の把握は重要な要素になってきます。 また、今回の内容を学べば、Gitの大枠を実装することもできてしまうので、興味がある方はぜひ挑戦してみてください。 Gitについての誤解 それでは、まずGitについて多くの人が誤解しているであろう点を挙げ
「仕事でWordをめちゃくちゃ使うんだけど、Gitみたいなソース管理、バージョン管理できないかな」やりたいのは差分比較→有識者から様々な提案が寄せられる
もくだいさん🇯🇵 365おじさん @mokudai 仕事でWordをめちゃくちゃ使うんだけど、Gitみたいなソース管理、バージョン管理できないかなぁ やりたいのは差分比較なんだよなぁ Wordなので文章の追加削除だけじゃなく、スタイルの適用、セクションの変更など全部比較したい。 。。。世の中には無さそうだなぁ もしあればだれか教えて！ #m365jp 2024-08-21 11:33:14 もくだいさん🇯🇵 365おじさん @mokudai セクションのスタイルを正しく使うと、「特定のセクション（中表紙とか）にはページ番号付けない」とか設定できるんですけど、さぼって白いオブジェクトで隠すやつがいるので、こういうのも駆逐したい。 pic.x.com/yotudzzdn0 2024-08-21 12:29:05
Jujutsu（jj）完全ガイド：Gitを超える次世代バージョン管理システムの実践活用法 はじめに Jujutsu（ジュジュツ、通称jj）は、Googleのエンジニアによって開発された次世代のバージョン管理システムです。「Gitと100%互換性がありながら、より使いやすい」という一見矛盾した目標を見事に実現しています。 本記事では、Jujutsuの基本概念から実践的な活用方法、さらにはAIツールとの並列開発まで、包括的に解説します。 目次 なぜJujutsuなのか？5分で分かる革新性 30秒で始めるJujutsu Gitユーザーが最初に知るべき5つの違い 実践：日常開発でのJujutsu活用法 コンフリクト処理の新しい考え方 GitとJujutsuの併用パターン AIツールとの並列開発 アーキテクチャ解説（上級者向け） よくある質問と移行ガイド なぜJujutsuなのか？ Gitの問題を解
緊急新人エンジニア応援企画！ ということで自分が Git のエイリアスとして設定している便利コマンドを紹介していく。 直前のコミットに追いコミットする (git fixit) git commit --amend --no-edit もろもろ整えて git push しよう、とすると「あっちょっと修正したい」となるのはよくあること。その際いちいちコミットメッセージを書いて rebase するかというとそんな面倒はとりたくなく、一撃で終わらせたい。--no-edit でコミットメッセージを編集せずに --amend できる。 git fixit に設定している。git commit の引数をそのまま受け付けるので、git fixit -a や git fixit <file> のように使える。 メインブランチに戻る (git com) f() { remote_head=$(git symb
2022.11.15に発表した内容になります。 https://www.youtube.com/watch?v=ScNN3uGXFd0
食品トレー原料PS、在庫2か月
サービス・商品食品トレーやカップ麺容器の原料になるポリスチレン（PS）樹脂の在庫が薄い。JPCA（石油化学工業協会）の月次統計から平時出荷ベースで単純計算すると、2か月分しかない。4月中旬以降、PSシートを起点にフィルム類でも値上げが続き、メーカーからは出荷制限や受注制限の通知も出始めた。（編集長・赤澤裕介） JPCAの月次統計によると、2025年12月末時点のPS在庫は8万4000トン、月間出荷は4万1500トンだった。単純計算で2.0か月分になる。石化協が3月17日に示したポリエチレン（PE）とポリプロピレン（PP）の在庫は国内需要の3.5〜4か月分だが、PSはその半分以下だ。3月時点で示された「4か月分」はPE/PPが中心で、PSの薄さまでは示していなかった。 在庫の薄さは、価格改定の速さにも表れ始めた。食品トレー原料のPS樹脂は、DICが4月1日納入分から1kgあたり100円以上、
もうこれ以下は無理というぐらい最低限なバージョン管理
いいからgit使え もうファイル名に日付とか「最終」とか付けるな．文字しか書いてないWordファイルとかExcel方眼紙とかはこの際目をつぶる．それはもう仕方ない．だがファイル名によるバージョン管理だけは駄目だ． まずGitHubにアカウントを作れ．そんな名前も知らない会社のウェブサービスは使いたくないだって？お前Word使ってるだろ． それからSourceTreeをインストールしろ．そんな名前も知らない（略）お前Trello使ってるだろ．使ってない？今すぐ使え． よし，準備は出来たな． 新しい仕事を始める時，まず何をする？そう，空のフォルダを作るよな．ちょっと待った．今後は手元のコンピュータ上に空のフォルダを作るんじゃなくて，GitHubに作るんだ．GitHubに作るフォルダはリポジトリと言うぞ．リポジトリはただのフォルダじゃなくて，ファイルの履歴を管理できるんだ．うっかり全世界公開して
Intro 前回は、Nx の事例をベースに「パッケージを公開する側」の対策について解説した。 今回は、「パッケージを使う側」、もっと言えば「OSS を使う上で開発者が考えるべきこと」について考察する。 OSS の危険性 npm 起因のサプライチェーン攻撃が確認されたことで「npm は危険だ」という話になると、「npm を禁止すべき」といった極端な話になったりする。 前回のブログで紹介したような対策を行うなら、多少は良くなるかもしれない。しかし、それらは全てパッケージ公開者に委ねられる。自分が公開者として実施するなら、自分が原因で攻撃が発生することは防げるだろう。 一方、攻撃に必要な突破口は 1 つあれば良い。npm にある全てのパッケージが対策されない限り、npm を主語とした安全が担保される日は来ない。 この広大な依存関係の中には、闇落ちした開発者が、それまでの善良なコードを、自分の意志
この記事はNuco Advent Calendar 2022の7日目の記事です はじめに 株式会社Nucoでエンジニアをしている@noshishiです。 今回は、ついついその場限りのコマンド実行で乗り越えがちなGitを、コマンドを使わず理解するための記事を書こうと思います。 Gitとは バージョンを管理し、作業を分散する Gitは、分散型バージョン管理システムと呼ばれるソースコードの管理システムの1種です。 Gitは、ファイルの変更履歴（バージョン）を記録・追跡することで、過去と現在のファイルを比較し、変更点を明らかにすることで、円滑に開発作業を進めるためのツールです。 また、一度に複数の開発者がファイルを編集できるシステムなので、作業を分散して行うことができます。 Gitを使うということ まず、みんなで共有できる保存場所（以下、リモートリポジトリ）にあるファイルなどを、手元のパソコン（以
いいコミットメッセージの共通点と書き方〜便利なテンプレートやチーム開発時のお作法まで詳しく解説〜 | PrAhaENGINEERLAB
Gitを用いた開発作業を行う際、意図がわからないメッセージのコミットを積み重ねていくと、コミットログを見る人の負担が増えたり、コミットログを活用する習慣がなくなっていき、開発効率の低下を招きます。この...
はじめに 「git stash し忘れてチェックアウトできない」 「git rebase でコンフリクトの嵐」 「git reset --hard で作業が消えた...」 Git を使っていて、こんな経験はありませんか？ jj（Jujutsu） は、これらの Git の痛みをすべて解消するために設計された、次世代のバージョン管理システムです。Google のエンジニアが開発し、Rust で書かれたこのツールは、Git リポジトリとの完全な互換性を持ちながら、根本的に優れたワークフローを提供します。 この記事では、jj の魅力と基本的な使い方を紹介します。 jj とは何か Jujutsu（柔術）は、Git と互換性のあるバージョン管理システムです。既存の Git リポジトリの上にレイヤーとして動作し、チームメイトに影響を与えることなく導入できます。 最大の特徴：ロックインなし jj は Gi
Claude Codeでバックオフィス業務のために「back-officeリポジトリ」を作ったほうがいいよ｜すてぃお
個人事業主や法人はとにかくバックオフィス業務が多いです。 経理・会計だと SaaSの請求書（領収書）を毎月集める クレジットカード明細と領収書を突合する 取引先へ請求書を発行する 入金された振込と自分が発行した請求書を突合する freeeに仕訳を切る 決算期に税理士さんに資料を渡す 法人税・消費税・地方税の申告対応（税理士経由） 資金調達・財務だと 信用金庫や日本政策金融公庫からの借入を管理する 借入の返済スケジュールを管理する 資金繰り表の更新 労務・社会保険だと 社会保険（健康保険・厚生年金）の加入手続き・届出 役員報酬の変更手続き（定時株主総会の議事録作成含む） 算定基礎届の提出 労働保険の年度更新 年末調整の対応 住民税の特別徴収の処理 補助金・助成金だと 補助金・助成金の申請書類の作成 交付決定後の実績報告書の作成 証拠書類（見積書・発注書・納品書・請求書・振込明細）の保管 報告
モノレポにすべきか、レポジトリを分割すべきか
先日 フロントエンドの Monorepo をやめてリポジトリ分割したワケ というブログがバズっていた。そのおかげか、Twitter でもモノレポに関する言及がちょこちょこあった。一家言あるドメインなので書きたい。ただの一家言(a.k.a お気持ち)なのでぜひ皆さんの意見も聞いてみたい。 tl;dr 別に自分はどっち派とかではなく、どっちも選ぶ。強いて言うならリポジトリ分割派で、依存更新がしんどくなったら monorepo 派。 免責 モノレポに対する一家言を書きたいだけであって、内容自体はフロントエンドの Monorepo をやめてリポジトリ分割したワケ と全く関係なく、そのブログで述べられている施策については何も言及しません。ただ一つ言及するとしたら肉の部位がコードネームに採用されているのは良いと思いました。🍖🍖🍖 モノレポにしたくなる状態の前提にあるもの 前提は元記事と同じように
Gitは最初1244行しかなかった
概要 Junio C Hamanoさんに興味を持って調べていると、Linusさんが書いたGitの初版は1244行ということが分かりました。Gitの初版について、軽く行数の確認とビルドチャレンジをして、あまり調べずに動かしながら機能を推測してみました。 はじめに Highlights from Git 2.39 の冒頭で登場するcommit数が一番多い方「Junio C Hamano」さんを知らなかったので調べてみました。 gihyoのインタビュー記事が面白かったです。Junio C HamanoさんはGitのメンテナで、LinusさんからGitのメンテナを引き継いだすごい方だということを知りました。 このgihyoのインタビュー記事の中で「MLで流れてきたGitのコード行数は1244行だった」というところが気になりました。調べてみると、2020年にTwitterでRui Ueyamaさんへ
ついに最強のCI/CDが完成した 〜巨大リポジトリで各チームが独立して・安全に・高速にリリースする〜 - ZOZO TECH BLOG
こんにちは。SRE部の巣立（@ksudate）です。 我々のチームでは、AWS上で多数のマイクロサービスを構築・運用しています。マイクロサービスが増えるにつれて、CI/CDの長期化やリリース手法の分散など様々な課題に直面しました。 本記事では、それらの課題をどのように解決したのかを紹介します。 目次 目次 はじめに CI/CDのこれまで Release PRによるリリース CI/CD実行時間の長期化 マイクロサービスごとのリリースが難しい リリーサーの制限ができない ドメイン単位の並行リリース リリース手法が分散する ブランチ間の同期が必要 パイプラインの増加 CI/CD実行時間の長期化 リリーサーを制限できない CI/CDの刷新 高速かつシンプルなCIパイプライン 変更差分を利用したCIパイプラインの実行 承認機能付きのCDパイプライン GitHub Environmentsによるリリー
こんにちは！ブロックチェーンチームでエンジニアをしている 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」ですが、Linuxカーネル開発のために作られたという経緯もあり、使いこなすにはかりの経験値が必要となります。 この問題を解決するために、Googleのソフトウェアエンジニアによって、新しいバージョン管理システム「Jujutsu」の開発が進められています。 Jujutsuの素晴らしさを紹介する記事「jj init 」によると、Jujutsuは過去のバージョン管理システムの問題点やメリットを分析して作られていて、Googleの既存のバージョン管理システムを置き換える勢いがあるとのこと。 JujutsuはmacOSでは、brew install jjを実行するだけで使用することができ、バックエンドとしてGitを使用しているため、採用にコストがかからないというメリットもあるそうです。 公式サイトでは、Jujutsuの特徴がリストアップされ
ソースコード管理の進化：Excel管理からGitHubまで、エンジニアの戦いを振り返る！ - Qiita
ソースコード管理の進化：Excel管理からGitHubまで、エンジニアの戦いを振り返る！ プロローグ 先日、弊社のとある案件内での会話です。 熟練エンジニア（以降「熟練」と表記）：GitHubのプルリクが来てたからコードレビューしておいたよ。 若手エンジニア（以降「若手」と表記）：ありがとうございます。助かります。 熟練：他の人のコードにも指摘した内容がキミのコードにもあったので指摘しておいた。他の人のプルリクは見ていないの？ 若手：いや、他の人のプルリクは見てないですね。。 必要ですかね・・？ 熟練：必要だよ。昔はそういうのやりたくてもできなかったんだから！ 若手：（はじまった、熟練さんの昔語り・・。長いんだよなぁ。。）なるほど！そうなんですね。他の人のコード読んで勉強します！ はじめに 皆さん、こんにちは。エンジニア歴約20年目の立脇です。今日は、エンジニアにとって切っても切り離せない
Metaが10年間にわたり開発・使用してきたソースコード管理システム「Sapling」がオープンソース化されました。Git互換で基本的なコマンドは類似しており、すべてのコマンドがシンプルで使いやすいように設計されているとのこと。Saplingは2022年11月15日から一般向けに公開されています。 Sapling: Source control that’s user-friendly and scalable https://engineering.fb.com/2022/11/15/open-source/sapling-source-control-scalable/ MetaはSaplingについて「ユーザビリティとスケーラビリティを重視した、Metaで使用されているソース管理システム」と紹介。GitやMercurialのユーザーにとって基本的な概念の多くがなじみのあるものであり、
はじめに 最近、AI エージェント（GitHub Copilot / Claude Code / Cursor / OpenCode / Codex …）に渡す「指示書」の種類が一気に増えました。 GitHub Copilot → .github/instructions/*.md, .github/prompts/*.md Claude Code → .claude/commands/*.md, .claude/agents/*.md Cursor → .cursor/rules/*.mdc これに加えて MCP サーバー / hooks / skills … チーム内でこれらを 「どこから集めて、どこに配っていますか？」 絵にすると、複数の取得元 × 複数のハーネス という多対多の配線を、各チーム／各リポが自前で組んでいるイメージです。 個々のツールが便利になっても、チーム全体としてこ
はじめに こんにちは！株式会社ダイニーの Platform Team に所属しています。0tanyです。 モダンなモジュラーモノリスアーキテクチャでは、環境変数の管理が重要な課題の一つです。事業成長とともにサービス数と環境数が増加すると、その管理複雑性は指数関数的に増大していきます。 本記事では、この移行を通じて得られた知見を共有します。同様の課題を抱えるチームの参考になれば幸いです。 従来のアーキテクチャの問題点 環境別の.env ファイルと Docker イメージの管理地獄 上記が従来のアーキテクチャです。ダイニーでは飲食店向けのモバイルオーダーサービスを 4 つの環境（develop/staging/beta/production）で運用しており、それぞれの環境に対して 4 つのサービス（web、backend、backend-online-payment、backend-reser
jjを使っていて驚いた「1つの変更を育てていく」という哲学 はじめに 前回の記事でjj (Jujutsu) の基本的な使い方を紹介しました。ファイルの変更が自動で記録され、コミットメッセージを後から書けるという便利さに魅了されて使い始めたのですが、使っているうちにもっと根本的な思想の違いに気づいてしまいました。 それは「1つの修正に対して1つの変更単位（change）を使い、説明を上書きしていく」というスタイルです。作業履歴はローカルにとどめ、共有するのは1つのchangeのみ。issueやPRに対してもchangeは1つで、手元の作業履歴をどんどん修正していきます。 つまり、複数のコミットを積み重ねるのではなく、1つの変更を完成するまで何度も更新し続けるのです。まるで盆栽を育てるように、同じ変更を丁寧に育てていくイメージです。 これは、Git/GitHubに慣れた私にとって大きな思想の転
エムスリー Advent Calendar 2025 4 日目の記事です。 クラウド型電子カルテのデジカル開発チームで色々なことをやっている井上 (@wtr_in) です。一年を通して伊藤園の天然ミネラル麦茶を愛飲していますが、最近どうも味が変わった気がしています。（しませんか？） さて、すでに当ブログでも過去に何人か記事を書いていますが、弊社では GitLab Server から GitHub Enterprise Cloud への移行を進めています。 www.m3tech.blog デジカルチームでもリポジトリごとに順次移行を進めていますが、その際に GitHub Actions を使って Pull Request のマージ方式を間違えないための仕組みを作ったので、その内容を紹介します。 先に3行でまとめ 抱えていた課題 前提: PR を Squash マージしたい そして生まれる人間
ジャスト・イン・タイムと在庫削減が“悪”になる時代
JITからのコペルニクス的転回か 筆者はサプライチェーンのコンサルティング会社に属している。コロナ禍以前と以後では、問い合わせの内容が異なっている。以前は、「働き方改革」「人工知能（AI）／RPA（Robotic Process Automation）の活用」といったテーマが多かった。 それがコロナ禍以後は、「働き方改革」はピタリとなくなった。それまで遅々としてテレワークなどは進まなかったのに、コロナ禍では背に腹は代えられないと、議論や手法論をすっ飛ばしてただちにテレワークの実践が進んだ。この日本人の火事場の転換力には感心した。一方でAIもRPAも現実的な応用に限界があると企業が感じたのか、次のデジタル・トランスフォーメーション（DX）にテーマが移っていった。 そして、コロナ禍以後に増えたのがコスト削減の相談や、在庫に関わる相談だ。コロナ禍が始まった直後はコスト削減についての相談が多かった
常々GitHubにtag requestが欲しいと言ってきましたが、それを実現するツールを作りました。OSSなど、バージョニングとリリースが伴うソフトウェア開発のリリースエンジニアリングをとにかく楽にしたいという動機です。既に自分が管理している幾つかのOSSでは導入して便利に利用しています。 https://github.com/Songmu/tagpr アイデア 基本の発想は以下のようにシンプルです。 リリース用のpull requestがGitHub Actionsで自動で作られる バージョン番号が書かれたファイルやCHANGELOG.mdを自動更新 そのpull requestをマージするとマージコミットに自動でバージョンtagが打たれる semver前提 リリース用のpull requestを自動で作りマージボタンを以てリリースと為す、というのは、みんな(僕が)大好き git-pr
より良いコミットメッセージを残すことは 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://
こんにちは！「家族アルバム みてね」（以下、みてね）SREグループのおじまです。 今回は、みてねの開発プロセスを支えるデプロイパイプライン、特にブランチ戦略を改善し、ステージング環境における占有問題などの課題を解決したお話をご紹介します。 みてねの開発フローとこれまでの課題みてねでは、ブランチ戦略としてGitHub Flowを採用しています。GitHub Flow では、はじめにメインブランチからフィーチャーブランチを作成します。フィーチャーブランチで機能開発を行った後、プルリクエストを作成します。フィーチャーブランチは、プルリクエストにおけるコードレビューを経て、メインブランチにマージされます。メインブランチは常にデプロイ可能な状態に保たれます。GitHub Flowは、シンプルで分かりやすいのが特徴です。 しかし、GitHub Flow自体には、本番環境以外へのデプロイ方法について明確
ロジカルなコミットメッセージの書き方
チーム開発におけるコミットメッセージの書き方についてアウトプットします。 コミットメッセージに正解はありません。 組織によって最適な手法は異なるため、参考のひとつにしてください。 要点 フォーマット :Emoji: Title / Reason / Specification / Issue 項目 Emoji - 内容・種類をひと目で分かるように Title - タイトル（概要） Reason - このコミットをする理由 Specification - 言い訳ではなく、このコミット内容になった意図や仕様など Issue - 対応するIssue 作業内容はコードを見ればわかるので、「概要」「変更理由」「意図・仕様」を簡潔にまとめる。 例 コミットメッセージを書く理由 そもそも、コミットメッセージを書く理由は以下の通りです。 ひと目でどんなコミットなのか判断するため 簡潔にコミット内容を説明す
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事の概要 執筆：段（Imperial College London・Nospare）、酒井（筑波大学・Nospare）、小林（明治大学・Nospare） この記事は製造業界に従事するもしくはこれから従事するデータサイエンティストのために製造業で用いられる統計・機械学習技術と具体的な応用事例の紹介をします。特に製造業の研究開発に必要な時間と費用を削減するための技術に焦点を当てます。具体的には： サロゲートモデリング（Surrogate Modelling）、 ベイズ最適実験計画法（Bayesian Optimal Experimen
開発者「すみません、なんかnpm iとかnpxコマンドがうまくいかなくて…」 ワイ「でたー、cb.apply is not a functionって書いてません？」 開発者「書いてます」 ワイ「ちょっと見てみますね」 ワイ「……これはnpm入れなおしたほうが早そうですね…」 ｶﾀｶﾀ… ワイ（うーん…なぜ未だにnodistで消耗しているのか…😨） TL;DR nodistはもうやめよう 選定するときは、まず選定基準を決めよう 関連技術の特徴を洗い出そう それらが自分たちの環境にどれくらいマッチするかで比較しよう Windowsならfnmがオススメ1！ ※ バージョン管理ツールがなんだかわからない方は「Node.jsのバージョン管理ツールとは」からお読みください。 うわっ…私の現場、nodist使いすぎ…？ Node.jsの利用が本格化してきたころ、私の周りでは圧倒的にnodistが流行し
フロントエンドの Monorepo をやめてリポジトリ分割したワケ - カミナシ エンジニアブログ
こんにちは。ソフトウェアエンジニアの坂井 (@manabusakai) です。 カミナシのプロダクトは、管理者の方が使う Web アプリに React、現場の方が使う iPad / iPhone アプリに React Native を採用しています。 どちらもフロントエンドの技術スタックを採用していることもあり、先日までは Monorepo と Yarn Workspaces の構成で運用されていました。 最近では Monorepo 化を進めている事例もよく見かけるようになってきました。 engineering.mercari.com devblog.thebase.in ですが、カミナシでは Monorepo をやめてリポジトリ分割をする意思決定を行いました。 具体的には、harami_client という Monorepo を harami_web と harami_mobile とい
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
LNGの専門家だけど、今後日本で起こりうる最悪の展開について書く
設計ドキュメント腐る問題、Git管理で運用してみた結果 | フューチャー技術ブログ
2024年Gitワークフロー再考 | フューチャー技術ブログ
ターミナルを使う人は、とりあえず「mise」を入れておく時代。 ・・・を夢見て。
たぶんもう怖くないGit ~Git内部の仕組み~ - Qiita
Gitの内部構造をよく理解して、うまく使おう【基本の仕組みを解説】
Jujutsu（jj）完全ガイド：Gitを超える次世代バージョン管理システムの実践活用法
Gitのおすすめエイリアス5選 - 詩と創作・思索のひろば
Git の最新アップデートから考える開発手法の潮流
サプライチェーン攻撃への防御策 | blog.jxck.io
コマンドを使わずに理解するGit - Qiita
Git の次へ。jj（Jujutsu）が変えるバージョン管理の常識
Git の Squash マージをやめた話 - Mobile Factory Tech Blog
Gitを置き換えるバージョン管理システム「Jujutsu」 | ソフトアンテナ
Metaの大規模ソースコード管理システム「Sapling」がオープンソース化
ハーネスエンジニアリングを楽にする Microsoft 製の新ツール「APM」ハンズオン
🧹.env にさよなら！全てのサービス開発者が実感するビルドプロセス改善🔐⏱️⚙️
jjを使っていて驚いた「1つの変更を育てていく」という哲学
GitHub のマージ方式を人間に毎回選ばせるのは、もうやめよう（やめた） - エムスリーテックブログ
リリース用のpull requestを自動作成し、マージされたら自動でタグを打つtagpr | おそらくはそれさえも平凡な日々
より良い Git コミットメッセージを書こう - Qiita
ブランチ戦略（GitHub Flow）を見直してステージング環境の運用を改善しました
製造業のための統計学・機械学習 - Qiita
💡 Node.jsのバージョン管理ツールを改めて選定する【2021年】 - Qiita
news.yahoo.co.jp
kininarubikenews.com
kuragebunch.com
toyokeizai.net
kuragebunch.com
minto.ag.ebb.jp