Gitの中身
はじめに Gitで管理するプロジェクトには.gitというディレクトリがあり、その中にGitの管理情報が入っている。その中には、全てのコミットや、いろんなバージョンのファイル、ブランチ、タグといった情報が格納されている。Gitを操作するにあたり、この中身がどうなっているかを理解する必要はないし、もし中身を覚えたとしても、操作方法は変わらないまま、内部実装だけ変更になる可能性もある。それでも、Gitの仕組み、特に様々な情報が.gitにどのように格納されているかを知っておくのは二つの理由から有用だと考える。 一つ目の理由は、「物が動く仕組み」を知っておくことが教養だからだ。車を運転するのに、アクセルを踏めば進み、ブレーキを踏めば止まり、ハンドルを回せば曲がることを知っていれば十分だ。しかし、シリンダーにガソリンが噴射され、ピストンで圧縮したところで点火し、爆発する力でピストンが押される、という直
日本のイチゴが大ヒット、アメリカで脚光の200億円調達ベンチャー。「世界で一人勝ち」の理由 | Business Insider Japan
オイシイファーム（Oishii Farm）の共同創業者兼CEO・古賀大貴氏は、「植物工場は日本が勝つべくして勝てる領域」と断言する。撮影：湯田陽子日本のイチゴが、ニューヨークで旋風を巻き起こしている。 アメリカを代表するフレンチ界の巨匠、ダニエル・ブリュー氏のミシュラン二つ星レストラン「ダニエル」をはじめ、味に惚れた有名レストランのパティシエから注文が殺到。ソースや飾りといった素材の一部ではなく、デザートの“主役”として、加工せずそのまま提供している店がほとんどだという。 レストランだけではない。高級スーパー・ホールフーズをはじめとする100店舗以上のスーパーでも販売。店頭に並ぶそばから飛ぶように売れている。 食通をうならせるこのイチゴ、生産しているのは日本人CEO率いるオイシイファーム（Oishii Farm）だ。 2016年にアメリカで創業した同社は、畑やビニールハウスではなく屋内の「
エンジニア未経験のわたしがGitを学ぶ上で、この流れで記事を読むべきだったと思ったことを記載する。 完全に初学者意見のため、疑いながら読んでください。 私は下記の流れで学習することによって、理解をしやすいように感じた。 ① Gitで何をしているかのイメージを掴む（コマンドなし） ② Gitのイメージを、コマンドで実現している記事をみる ③ 実際にGitのコマンドを打ちながら、出力と、頭の中のイメージのすり合わせ Gitで何をしているかのイメージを掴む（コマンドなし） こちらの記事は、Gitのイメージをコマンドなしで、わかりやすく図で示してくださっています。 記事にも記載されていますが、 ・重要なのは 「何」から「何」へ・「どんな作業」を行う のかを追う ・操作前と操作後でどんなことが起こっているのかをイメージする 上記の内容が、すごく同意で、重要だと感じている。いきなりコマンドを打ちながら
貿易関係の増田が現状をまとめてくれてたので（anond:20260313174445）、自分はもう少し踏み込んで「今後50%くらいの確率で起こりうる最悪の展開」について書いてみる。電力・ガス関係の仕事をしている立場から。 先に言っておくと、これは「確実に起こる」話ではない。ただし「起こってもおかしくない」話だ。 ■前提の整理 まず数字の確認から。日本の電源構成のうちLNG火力は約3割。日本のLNG輸入における中東依存度（カタール＋UAE＋オマーン）は約11%。「なんだ、たった11%か」と思った人は少し待ってほしい。 問題は3つある。 1つ目。カタールは世界のLNG輸出の約20%を占めるメガサプライヤーだということ。カタールが止まると「日本のカタール依存5%」の問題ではなく、世界のLNGスポット市場全体が干上がる。3月2日にJKM（日韓向けLNG指標価格）が一時40%近く跳ねたのはそのため。
個人用メモです。 「git gcってあんまし容量減らないよなぁ」 と思ったのが動機です。調べたけどパッと腑に落ちる記事がなかったので「自分で git のソースコード見た方がいいな」と急にモチベ発動してグワっと勉強しました。またついでに歴史改変の方法も調べたのですが、公式で既に WARNING が出てるほど非推奨化されてるfilter-branchを使用してる記事が多かったので、2021 年現在で多分一番推奨されてるfilter-repoを使ってやる方法もまとめました。 ちなみに容量減らしても高速化するかというとそこまで単純ではないです。そもそも減らさなくても partial clone で blob オブジェクトを必要最低限に指定して昔の blob をデフォルトで持ってこないようにしたり(--no-checkoutと併用するとより効果有る)、その後本当に自分が必要なやつだけ sparse-
仕組みから理解するGit
📚 本書について【無料公開中】 Gitの内部の仕組みを徹底的に丁寧に解説する本です。 「Gitはいかにバージョンを管理しているのか？」 「コミットはスナップショットと聞いたことがあるものの、どういう意味？」 「操作時にエラー表示をネットの記事を参考に対応しているけれど、実はよく分かっていない...」 といった疑問をすべて解決する基礎力を身につけることができます。 Gitの仕組みを理解することで、普段使いのツールとしても、より効果的に利用できるようになるほか、データ構造やアルゴリズムの学習用途としても楽しめるような構成になっています。
Gitのワークフロー、好みが分かれる分野で自転車置き場の議論にもなりがちだと感じている。基本的にはプロジェクトの流儀に素直に従い、余計なストレスを抱えないのが良いと考えている。例えば、私はマージコミットを作るのが好みだが、OSS活動等では「squash & mergeして」って言われることもあり、そういうときは当然素直に従うようにしている。 ということで、私のGitのワークフローについてのスタンスについて書いておこうと思う。私と一緒に働く人や、働くことを検討している人の参考になればと思います。もちろん、この辺りは、良い方向に変化もさせていきたい。例えばエントリー内でも触れていますが、私は昔はforce pushを禁止したいくらいでしたが、今は使っても良い、と思うようになりました。 Natureの特にGoでのバックエンド開発はこれに近い感じだとイメージしてもらえればと思います。ただ、できてな
Note 本記事の内容は Linus 氏の発言が人を傷つける場合に筆者がそれを良しと考えるといった意図はございません 少し古い記事になるが、 Linus Torvalds 氏 の GitHub に対する苦言が記事になっていた。 LinuxカーネルにNTFSドライバーが追加、トーバルズ氏はGitHub経由のマージに苦言 - ZDNet Japan Linus 氏が GitHub について苦言を呈するのは今に始まったことではない（後述）が、 別に GitHub のすべてを否定しているわけではない。[1] では一体何が不満なのか。Linus 氏の理想とする git の開発フローを考察した上で、整理してみたい。 Linus 氏の理想 結論からいうと、 「意味あるコミットを作れ」「コミットを大事にしろ」 という思想が伺える。 では 「意味あるコミット」「大事にされたコミット」 とは何なのか。 筆者な
GitHub上のsensitive dataを削除するための手順と道のり | メルカリエンジニアリング
Advent Calendar day 7 担当の vvakame です。 予告では Apollo Federation Gateway Node.js実装についてポイント解説 としていましたが、社内各所のご協力によりAdvent Calendarの私の担当日に間に合う形で公開できる運びとなりました。そのため告知とは異なりますが GitHub上のsensitive data削除の手順と道のり をお届けしていきたいと思います。 メルペイVPoE hidekによるday 1の記事で振り返りがあったように、今年、弊社ではCodecovのBash Uploaderに係る情報流出という事案が発生しました。当該インシデント対応において、プレスリリースにも記載のある通り、ソースコード上に混入してしまった認証情報や一部個人情報などの機密性の高い情報（sensitive data）について調査を実施し、対応
はじめに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コマンドで実行する機能です。 ※設定ファイルはグローバルで有効
Gitのワークフローについては自転車置き場の議論になりがちであまり乗り気がしないのですが、最近少し発見があったのと、実際に多くの現場で明らかにフィットしないのに git-flow を検討したり採用したりしようとして苦労をしている様を目撃することが多いので書くことにしました。 この記事で主張する内容はタイトルの通りですが、まず前提として以下を宣言しておきます: 全てのケースに100%フィットするようなワークフローは存在しない git-flowがフィットするケースも探せばあるかもしれない 例えばすでに何年もgit-flowでうまく回せてるよ、など どのようなワークフローを採用するかは最終的にはあなた（のチーム）が判断すべき さて、 git-flow は 2010年1月「A successful Git branching model」というブログポストによってバズり、以来多くの人が参考にしてき
ヘリウム途絶、在庫切れへの秒読み
国際カタールのヘリウム生産が止まって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
画面設計書を Markdown で書く文化を浸透させたい
1. はじめに 実務では、画面設計書が Excel や PowerPoint、Word で管理されていることが多いです。 それ自体は珍しくありませんし、提出物としては都合が良い場面もあります。 ただ、開発の現場で実際に使う設計資料として見ると、つらいことが多いです。 どこが変わったのか差分が追いづらい レビューで変更点に集中しづらい 実装と設計書の同期が崩れやすい コピー運用で古い記述が残る 画面ごとに表現がばらつきやすい その結果、画面設計書が「あるけど信用されない文書」になってしまうことがあります。 自分は最近、画面設計書をもっとドキュメントベース、できれば Markdown ベースで書く文化を浸透させたいと考えています。 今回はその理由を整理してみます。 2. なぜ今の画面設計書運用がつらいのか 画面設計書は、多くの現場で Excel / Word / PowerPoint などの
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
え？まだgit checkoutしてるの？
公式ドキュメントには以下のように書かれています。 THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE. 和訳：このコマンドは実験的です。動作が変更される可能性があります。 この記事の内容と違う場合があるので、ご注意ください。 この記事は2024年2月28日時点の情報です。 え？まだgit checkoutしてるの？ git checkoutといえば、ブランチを切り替えたり、git addしたファイルを元に戻したりするコマンドですが、それはもう古いです。 実は2019年8月リリースのgit 2.23からgit switchとgit restoreが追加されました。 知らなかった人も多いのではないでしょうか？(恥ずかしながら私は知らなかった...) 「先輩、checkoutってなんすか？」と後輩に聞かれる前に、この記事を読んでgit sw
Claude Codeでバックオフィス業務のために「back-officeリポジトリ」を作ったほうがいいよ｜すてぃお
個人事業主や法人はとにかくバックオフィス業務が多いです。 経理・会計だと SaaSの請求書（領収書）を毎月集める クレジットカード明細と領収書を突合する 取引先へ請求書を発行する 入金された振込と自分が発行した請求書を突合する freeeに仕訳を切る 決算期に税理士さんに資料を渡す 法人税・消費税・地方税の申告対応（税理士経由） 資金調達・財務だと 信用金庫や日本政策金融公庫からの借入を管理する 借入の返済スケジュールを管理する 資金繰り表の更新 労務・社会保険だと 社会保険（健康保険・厚生年金）の加入手続き・届出 役員報酬の変更手続き（定時株主総会の議事録作成含む） 算定基礎届の提出 労働保険の年度更新 年末調整の対応 住民税の特別徴収の処理 補助金・助成金だと 補助金・助成金の申請書類の作成 交付決定後の実績報告書の作成 証拠書類（見積書・発注書・納品書・請求書・振込明細）の保管 報告
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
モノレポにすべきか、レポジトリを分割すべきか
先日 フロントエンドの Monorepo をやめてリポジトリ分割したワケ というブログがバズっていた。そのおかげか、Twitter でもモノレポに関する言及がちょこちょこあった。一家言あるドメインなので書きたい。ただの一家言(a.k.a お気持ち)なのでぜひ皆さんの意見も聞いてみたい。 tl;dr 別に自分はどっち派とかではなく、どっちも選ぶ。強いて言うならリポジトリ分割派で、依存更新がしんどくなったら monorepo 派。 免責 モノレポに対する一家言を書きたいだけであって、内容自体はフロントエンドの Monorepo をやめてリポジトリ分割したワケ と全く関係なく、そのブログで述べられている施策については何も言及しません。ただ一つ言及するとしたら肉の部位がコードネームに採用されているのは良いと思いました。🍖🍖🍖 モノレポにしたくなる状態の前提にあるもの 前提は元記事と同じように
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 直下にリポジトリと並んでワークツリーディレクトリがあると、理由あってワー
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さんへ
いちばんやさしいGit入門
20190425 JJUG ナイトセミナー
はじめに Claude Code、GitHub Copilot、Cursor など、様々な AI ツールが同時に複数のタスクを並行して処理することを可能にしました。しかし、従来の Git ワークフローでは、ブランチ間の切り替えによる作業の中断や、複数のタスクを同時進行する際のコンフリクトが課題となっています。 そこで注目されているのがGit Worktreeです。この記事では、Git Worktree の基本概念と使い方を紹介します。 従来の Git ワークフローの課題 ブランチ切り替えの問題点 従来の Git ワークフローでは、異なる機能やバグ修正を行う際にgit checkoutやgit switchでブランチを切り替える必要がありました： # 機能Aの開発中... git add . git commit -m "WIP: 機能Aの途中" # 緊急のバグ修正が必要 git switc
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
ついに最強の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によるリリー
Gitのオブジェクトの中身
はじめに Gitのインデックスの中身、Gitのブランチの実装に続く、Gitの中身を見てみようシリーズです。Gitが管理するオブジェクトの種類や中身について見てみます。基本的にはPro Gitの10. Gitの内側をまとめなおしたものです。 オブジェクトの種類 Gitは、内部でファイルやコミットを「オブジェクト」として.git/objects以下に保存しています。オブジェクトには以下の4種類があります。 blobオブジェクト： ファイルを圧縮したもの。ファイルシステムの「ファイル」に対応 treeオブジェクト： Blobオブジェクトや別のTreeオブジェクトを管理する。ファイルシステムの「ディレクトリ」に対応 コミットオブジェクト： Treeオブジェクトを包んだもの。コミットのスナップショットに対応するTreeオブジェクトに、親コミット、コミットメッセージなどを付加する タグオブジェクト：
こんにちは！ブロックチェーンチームでエンジニアをしている 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
これは何 僕は開発作業をしているとき、PRをあげるまでの開発途中はwipコミットに変更を記録していき、最後にコミットを仕上げていくような作業をよくします。 初めからコミットを綺麗に書きながら開発ができれば良いのですが、 にあるようなコミットログを仕上げていこうと思うとどうしても最後にコミットログを整理したくなります。 この記事はこのようにgitを使うと綺麗なコミットログを作れるよ、というTipsです。 具体的にこういうコミットを作ると良いよ、みたいな話はこの記事ではしません。 僕はこのような工程でPRを出す前にコミットログを作っています。 git rebase -iで作業中のコミットを全て一つのコミットにsquashする git reset HEAD~で一度コミットを取り消す git add -pで作りたいコミットごとに変更をstageにあげていく コミットを作成する git rebase
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
初学者の私がGitを理解するために、この順番で読めばよかったと思った記事の順番 - Qiita
LNGの専門家だけど、今後日本で起こりうる最悪の展開について書く
git gc の仕組みを原理から理解してサイズを 136MB → 7.2MB(95%減)まで削減した時の勉強メモ
Gitのワークフローについての私のスタンス | おそらくはそれさえも平凡な日々
Linus Torvalds 氏の理想の git 運用と GitHub
設計ドキュメント腐る問題、Git管理で運用してみた結果 | フューチャー技術ブログ
2024年Gitワークフロー再考 | フューチャー技術ブログ
ターミナルを使う人は、とりあえず「mise」を入れておく時代。 ・・・を夢見て。
特別な理由なしにgit-flowを新規採用するべきではない - Qiita
たぶんもう怖くないGit ~Git内部の仕組み~ - Qiita
Gitの内部構造をよく理解して、うまく使おう【基本の仕組みを解説】
Jujutsu（jj）完全ガイド：Gitを超える次世代バージョン管理システムの実践活用法
Gitのおすすめエイリアス5選 - 詩と創作・思索のひろば
Git の最新アップデートから考える開発手法の潮流
サプライチェーン攻撃への防御策 | blog.jxck.io
コマンドを使わずに理解するGit - Qiita
Git の次へ。jj（Jujutsu）が変えるバージョン管理の常識
なぜファイルの末尾に改行を入れたほうが良いのか - Qiita
AIエージェントで並列実装なら必須技術！ Git Worktree を理解する
Gitを使ってやらかした時、git reflogさえ使えればわりかしなんとかなる - Qiita
Git の Squash マージをやめた話 - Mobile Factory Tech Blog
綺麗なコミットログを作りたいときのgitテクニック - Qiita
ameblo.jp/koi-kentei
ameblo.jp/giida
ameblo.jp/giida
usedemikuray.hatenablog.com
taisy0.com
northwood.blog.fc2.com