TL;DR プロダクトの構成要素が多数の Git リポジトリに分かれているが、モノリポ化するのは大変。でもコーディングエージェントにはモノリポのほうが文脈与えやすくて、どうしよう。そんなあなたに virtual monorepo パターンと実際の使い方を指南します。 Claude Code をはじめとするコーディングエージェントを一切使わないというのは、今や難しいご時世かと思います。 私も多用していますが、その話はまた後日に。今回は身の回りでそれなりに流行している virtual monorepo というパターンを紹介します。 Virtual monorepo の初出はたぶん以下の記事だと思います。中身は後で解説しますがとてもシンプルで、それが故かあまり採用事例が公になっているのを見かけません。 手軽でかつ効果的なので、枯れ木も山の賑わいと思い、本記事を書いています。 medium.com
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 前書き 私がこの記事を書く理由は、近年、生成AIによる実装が当たり前になりつつあり、AIに対する「指示書」としてのドキュメントが改めて注目されていると感じているからです。その流れの中で、「仕様書駆動開発」という考え方も登場してきました。 自律型のAIエージェントがプロジェクト全体のコードを理解するためには、コードが一つのディレクトリ階層にまとまっている方が都合がよく、その文脈から「モノレポの方がAI時代には有効ではないか」という意見も増えています。 一方で、私自身の経験を振り返ると、モノレポには運用フェーズに入ってから顕在化する欠点が少
こんにちは、とまだです。 「このブランチで作業中なのに、急に別のブランチを確認しないといけなくなった...」 「でも今の作業は中途半端だし、コミットやスタッシュで退避するのもなぁ...」 こんな経験はありませんか? Gitでの開発では、複数のタスクを並行して進める場面がよくあります。 そんなとき便利なのが Git worktree という機能です。 今回は、Gitの基礎を押さえながら、worktreeの使い方を初心者の方にもわかりやすく解説します。 また、Anthropic社もGit worktreeの活用を推奨しており、AI駆動開発でも活用できますのでぜひ覚えていってください！ Claude Codeの公式ベストプラクティスについては、別な記事で詳しく解説しています。 著者について とまだ Claude Code・Cursor・Codex などAI駆動開発の実践者 本業はフリーランスエン
サービス開発部Backlog課の@vvatanabeです。今年の4月にSRE課からBacklog課へ異動しました。よりプロダクトにコミットしていく機運の高まりを感じています。 今回は、Backlogが提供するGitホスティングにおいて、可用性・信頼性を保つためにどのように冗長化と負荷分散を実現しているのか、その仕組みについて解説します。 ※ 本記事はNuCon mini 2022 Springで発表した内容をブログ化したものです。 取り扱うデータの特性 初めに、Gitホスティングで取り扱うデータの特性について解説します。 リポジトリという単位のオブジェクトデータベース Gitホスティングではベアリポジトリと呼ばれるリポジトリを取り扱います。ベアリポジトリとはワークツリーを持たないリポジトリです。具体的には、ローカルマシンに git clone して使っているリポジトリ内の、 .git ディ
こんにちは。Backlog のソフトウェアエンジニアの中村です。 とくに Backlog の Git 機能の開発と運用を担当しています。 ……そう聞いても、「具体的にどんなことをしているの？」とピンとこない方も多いのではないでしょうか。課題管理やECサイトならイメージしやすいかもしれませんが、SaaSとしてGitを提供しているサービスはあまり多くないですよね。 Git チームは、DevOps なチームとしてGit機能の開発と運用の両方を担っています。この記事では、私たちが日々どのようなシステムや課題に取り組んでいるのか、その裏側をご紹介します。 Git 機能のアーキテクチャの全体像 まずは、Backlog の Git 機能がどのような構成で動いているのか、ざっくりと説明します。 Git 機能のアーキテクチャ概要 ユーザーからのリクエストは、Web、API、HTTP、SSHといった様々な入り
semantic-commit-messages.md Semantic Commit Messages See how a minor change to your commit message style can make you a better programmer. Format: <type>(<scope>): <subject> <scope> is optional Example feat: add hat wobble ^--^ ^------------^ | | | +-> Summary in present tense. | +-------> Type: chore, docs, feat, fix, refactor, style, or test. More Examples: feat: (new feature for the user, not a
仕事でGit使うときとか普段とは違う会社のメアドでコミットとかしたいんだけど、cloneするたびに git config user.email とかするのメンドイよね〜 というかもうだいぶ有名な設定だと思うんだけどたまに知らない人いるので書いておくと includeif 使うと特定のディレクトリ以下のときに読み込む設定を変更できるので便利です。 で、ここまでは普通にGitのマニュアルにも書いてあるんだけど ghq と組み合わせると最高便利になるのでそのへんの設定を書いておきます。 といっても普通に設定するだけだけど .gitconfig には下記のように書いておいて [ghq] root = ~/src [includeIf "gitdir:~/src/github.com/launchableinc/"] path = ~/.config/git/launchable.inc ~/.co
ウクライナのソフトウェア開発者Dmitry Zaporozhets氏が2011年10月に、たった1人で開始したオープンソースプロジェクト「GitLab」。それが、ちょうど10年を経て時価総額1兆円もうかがうほどの大成功したDevOpsのSaaSプラットフォームへと進化することになると想像した人は、ほとんどいなかったと思います。GitLabのライセンス・SaaSビジネスを展開するGitLab Inc.は9月17日付けで米国証券取引委員会（SEC）に対してFORM S-1を提出し、IPOへ向けて最終段階に入りました。 開発初期から生まれたモメンタムと、それを生かした分散開発の組織化、VC投資を組み合わせた株式会社としての成長といったことから学べることは少なくないと思います。この記事では、GitLabの成功から学べる4つの教訓について書いてみたいと思います。 DevOpsという言葉が広まる前にス
小ネタで恐縮です。 参考: Highlights from Git 2.28 - The GitHub Blog 上のお知らせにあるように、Gitが2.28でデフォルトブランチ名をカスタマイズ可能になりました。従来はmasterがハードコードされていたのだそうです。 必要が無い限りUbuntu付属のバージョンから上げることないんだけど、今回は今後に備えてapt repo追加して git config --global init.defaultBranch main をかました。https://t.co/EGNkvhceSC — masa寿司 (@masa_iwasaki) July 28, 2020 たとえばgit initで作成されるデフォルトのブランチ名をmasterからmainにするにはGit 2.28以降にアップグレードしたうえで以下を実行します。 git config --glo
https://martinfowler.com/articles/branching-patterns.html 最新のソース管理システムには、ソースコードのブランチを簡単に作成できる強力なツールが用意されています。しかし、最終的にはこれらのブランチをマージしなければならず、多くのチームは混み合ったブランチに対処するのに膨大な時間を費やしています。複数の開発者の作業をインテグレーションし、本番リリースまでの道筋を整理することに集中して、チームが効果的にブランチを利用できるようにするためのパターンがいくつかあります。全体的なテーマとしては、ブランチを頻繁にインテグレーションし、最小限の労力で本番環境に展開できる健全なメインラインを作ることに注力すべきだということです。 ベースパターン ソースブランチング ✣ メインライン ✣ 健全なブランチ ✣ インテグレーションパターン メインラインイン
About git-flowはgitの拡張であり、Vincent Driessenの提唱するブランチモデルを実現するための高度なリポジトリ操作を提供します。 more ★ ★ ★ このチートシートは基本的な使い方とgit-flowの効果を表します。 ★ ★ ★ Basic tips Git flow は素晴らしいコマンドライン補助と出力を提供します。何が起こるか注意深く読み解いてください。 macOS Clientの Sourcetree は素晴らしいGUIとgit-flowサポートを提供します。 - Git-flow はマージすることをベースとして考えるソリューションです。リベースは行いません。 ★ ★ ★ macOS Homebrew $ brew install git-flow-avh Macports $ port install git-flow-avh Linux $ apt
Fork is getting better and better day after day and we are happy to share our results with you.
Gitリポジトリの簡単なビュワーとクローンツールを作った時のTipsをまとめました。 ローカルサーバーにある中央リポジトリの閲覧・検索をするために作成したものです。 最初はC++とLibGit2の組み合わせで始めたのですが、最終形はWindows/GUIにしたかったので途中でC#とLibGit2Sharpに乗り換えました。 C#初心者です。LINQやらIEnumerableやらTaskやらあって刺激的。C#おもしろい。 この記事では VisualStudio 2013 を使っています。LibGit2Sharp のバージョンは 0.22.0です。 LibGit2Sharpって何？ LibGit2とはその字面通りGitリポジトリを操作するライブラリ(API)です。C言語用です。*"2"*というからには不出来な兄または姉が居たと想像しています。 後ろに"Sharp"がついたものがC#言語用です。
最近、自分のGitのコミットログを読み返してみたら、すごく分かりづらかったので勉強も兼ねて、Gitのコミットログのプラクティスを勉強してみました！ 🐰 Gitのコミットメッセージの書き方次のサイトを参考にさせていただきつつ、簡単にまとめてみました！ Gitのコミットメッセージの書き方 | プログラミング | POSTD Gitのコミットメッセージの書き方 - Qiita 書き方を知ることのメリットGitのコミットメッセージをわかりやすく残すことで、その変更どんな目的で具体的にどんなことを修正したかを 次の変更を行う人に伝えることができ、次の人の修正する時間を節約できる。 具体的にどんなことを書くべきかどのように変更を行ったかは、コードを見れば分かる。もしわからないのなら、コードにコメントを書くべき。 変更した理由を明らかにすることに焦点を絞り、変更前がどうで、何が問題で、今はどのように機
# GitBook Setup Agent ## Task Take my docs and turn them into a live, published GitBook site. Go end-to-end — don't stop until it's live or you hit a step only I can do. ## Tooling You have two ways to work with GitBook. Check what's available and pick accordingly: 1. **GitBook MCP server** (preferred if already connected) — check your available tools for `gitbook-mcp`. If it's connected, use it.
はじめに みなさまのプロジェクトではどのようにバージョン管理を行っているでしょうか。 ここでのバージョン管理とは具体的にはどのようなブランチを作ってどこにマージするか、リリースはどのように進めるかといった事柄を指しています。 今日は数あるバージョン管理戦略の中で比較的新しく提唱されたGitlab flowというフローを中心にして話していきたいと思います。 最近アプリの開発においてこのGitlab flowが個人的には一番しっくり来ているのでオススメしたいです。 有名なフロー gitは分散型のバージョン管理システムとして一世を風靡しており、いまや事実上のデファクトスタンダートです。 名前のとおり分散している（ローカル・リモートが明確に分かれている）ことやブランチ・コミットの編集も非常に容易で柔軟性が非常に高いです。 一方でその柔軟さゆえにルールをきちんと決めなければ各個人のフローが大きく異な
Protected branches and required status checks もうお済みですか！？ 9月4日のことですがgithubより以下の機能がリリースされています。 特定ブランチへのforce pushを無効する 特定ブランチへのマージ時にステータスチェックを必須にする(CIと連携している場合は、テストが通るまでマージできないようにできる) これを実施することで、ある日新人が謎の空のコミットをmasterブランチにforce pushして来たり、ある日途中からJOINした人がpull reqもせずにdevelopブランチに謎コミットをforce pushして来たり、ある日とあるOSSで間違えて一ヶ月前のローカルレポジトリをgit push --forceしてしまうなんてこともなくなるんです！！！(githubを使っていれば) あなたの隣のエンジニアが、いきなり発狂して口
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに この記事は How to write the perfect pull request - GitHub を和訳というか、意訳した記事です。 ご指摘などありましたら大歓迎です！ 良いプルリクエストを書くには (原題 : How to write the perfect pull request) 会社が成長していくと、人もプロジェクトも様変わりしていきます。GitHubの中に私達が望む文化を育んでいくためには、我々が何を自覚してコミュニケーションするべきなのか分かってきました。私達のチームが最強であり続けるために、最近以下のよ
技術部のid:gfxです。iOSアプリ開発に欠かせないパッケージ管理ツールといえばCocoaPodsですが、これはPrivate Podsを作って社内ライブラリ専用のSpecs（private Specs）を管理することができます。 ※ 2014/12/22追記 CocoaPods 0.35.0 でpod lintの--only-errorsが廃止されて--allow-warningsになったのでそのように変更しました private SpecsがなくてもGit URLを指定することで社内用podspecを開発・管理することはできますが、private SpecsがあるとURL指定を簡略化したり依存関係の解決が簡単になるというメリットがあります。クックパッドでもすでに十数個のprivate podspecが登録されており、CookpadUIやAPI clientなどはpodspecとしてp
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
