この記事の対象読者 モノリポを複数運用することにしたが、一部のコードをライブラリとしてモノリポ間で共有したい（Googleみたいに一つのリポジトリに入れるのは嫌という人） 依存しているNPMパッケージにバグがあり、PRを出しつつ直したバージョンを使いたい プライベートリポジトリで作っているコードの一部を、ライブラリとしてパブリックなリポジトリで公開したい と、グダグダ書きましたが要は ↓ のような状況を上手に扱うにはどのようにすればいいかを説明していきます。 Git Submodule Git Submoduleは、あるリポジトリの中で別のリポジトリを参照し、管理するためのツールです。 今回なら、モノリポにライブラリのリポジトリを追加し、管理するために使います。 この記事で細かくGit submoduleについて説明するつもりはないので、詳しく知りたい方は公式ドキュメントを参照してください。 Yarn Workspace Yarn Workspaceは、Yarnを使ってモノリポを運用するためのツールです。 例えば、 app/package.json lib1/package.json package.json というような構造があったときに、appの中のコードでrequire('lib1')などということができるようになります。 こちらも詳しく説明するつもりはないので、公式ドキュメントへのリンクを掲載しておきます。 実際にやってみる 今回は、下記のリポジトリを用いて説明していくことにします。 submodule （submoduleはライブラリ用のリポジトリでRollupのテンプレート1を使って用意しました。） monorepo1 まずmonorepo1の中でsubmoduleを利用するには、monorepo1のリポジトリでgit submodule addを実行します。 git submodule add https://github.com/coder-ka/submodule この操作により、 submodule フォルダ .gitmodules ファイル が追加されます。 .gitmodules の中をのぞくと [submodule "submodule"] path = submodule url = https://github.com/coder-ka/submodule となっており、"submodule"というリポジトリがsubmoduleとしてsubmodule/ディレクトリで管理されているということがわかります。（名前がややこしくてすいません） ここで、submoduleの中のpackage.jsonの"name"キーを@coder-ka/submoduleに変更しておいてください。（これによりrequire('@coder-ka/submodule')となる） つぎは、Yarn Workspaceです。 まずリポジトリルートで初期化を行います。 yarn init -y そして、生成したpackage.jsonの内容を変更します。 { "private": true, "workspaces": [ "app", "submodule" ] } このpackage.jsonはWorkspace管理のためのものなので"private" :trueが必須になっています。（NPMリポジトリで公開しないため） また、"workspaces"にはモノリポ内のリポジトリとして扱うフォルダのパスを配列で指定します。（packages/*みたいな指定の仕方もできますが、今回は割愛） submoduleは先ほど追加したので存在しますが、appフォルダがないので作ります。 mkdir app # ついでに初期化 cd app yarn init -y また、リポジトリ内であればどこでもいいので yarn コマンドを実行しておきます。 yarn これにより、各ワークスペースが依存するパッケージがインストールされ、リポジトリのルートフォルダにnode_modules/が配置されます。（さらにnode_modules/@coder-ka/submodule/ は submodule/ へのSymlinkなので、ライブラリへの変更が即座に反映される） 次に app/index.js を作成し、コードを書きます。 index.js const howLongTillLunch = require('@coder-ka/submodule') console.log('it will be lunchtime in ' + howLongTillLunch()); そして、今回に限っては使っているテンプレートの都合でRollupによるビルドを行う必要がありますが、これは本質的な内容ではないのであまり気にしないでください。 # submodule/フォルダで yarn build しているのと同じ yarn workspace @coder-ka/submodule build これで app/index.js が正常に動くようになるので、 node app/index.js とすれば、it will be lunchtime in 18 hours とコンソールに出てきます。 これで無事に別リポジトリで管理しているライブラリを別のモノリポ内で動かすことができました。 懸念点と解決策 考えられる懸念点と解決策について書いていきます。 複数のモノリポからの依存 複数のモノリポからライブラリのリポジトリが参照される構成になると、ライブラリへの変更によるほかのモノリポに対する影響が気になってきます。 そんな時は、下記のような運用が良いと思われます。 例えば、 submodule monorepo1 monorepo2 がある場合は、submoduleのリポジトリにmonorepo1/monorepo2のブランチを作成し、それぞれのモジュールの変更はそのブランチに反映させるようにします。 Git Submoduleはデフォルトではmasterを参照するので、.gitmodulesにbranchを追加します。 [submodule "submodule"] path = submodule url = https://github.com/coder-ka/submodule branch = monorepo1 これで git submodule update --remote（サブモジュールの更新） をしたときにmonorepo1の内容を参照してくれます。 master には monorepo1 での運用で動作が安定していることが確認できた後に反映すれば、monorepo2 はそれを取り込むことができます。（もちろん、直接 monorepo1 から取り込むこともできます） 終わりに Git Submodule + Yarn Workspace の組み合わせが有用であることが理解いただけたでしょうか？ 今までは、公開や変更の手間などを気にしてライブラリを別リポジトリで作ることを躊躇していた方もいるかもしれませんが、この方法なら無理なくライブラリを運用かつ利用していくことができます。 ライブラリとして公開できる汎用性を持ったコードを作ることは、それにかかわるコミュニティをどんどん便利なものにしていってくれます。 是非この運用法を活用して、生産性向上に役立てていただければと思います。 Rollup公式のTypeScriptのUMDライブラリのテンプレートにava（テストフレームワーク）を私が追加したもの ↩

はじめに コミットメッセージの入力などでVScodeを使えるように設定していく手順を解説していきます。 前提として、Gitはローカル環境にインストールした状態にしておいてください。 GitのエディターにVScodeを設定する VScodeをGitのエディターとして登録するために、以下のコマンドをターミナルで実行しましょう。 $ git config --global core.editor 'code --wait' 次に、gitにVScodeがエディターとして登録されたか確認するために以下のコマンドを実行してみましょう。 $ git config core.editor 下記のように応答されればしっかり設定されています。 code --wait しかし、これだけではコミットしたときにVScodeが立ち上がってくれません。 ためにし「git commit」と入力すると・・・ hint: Waiting for your editor to close the file... code --wait: code: command not found error: There was a problem with the editor 'code --wait'. Please supply the message using either -m or -F option. このようなエラーが返ってきてしまいます。 これの解決方法を次で解説していきます。 VScode側でGitと連携するための設定をする まず、VScodeを起動してください。 起動できたら「Command Palette(⇧⌘P)」の入力欄に「shell command」と入力し、下図ような選択肢が出てきたら「〜をインストールします」の方を選択しインストールを実行します。 次にターミナルで以下のコマンドを実行し、表示されたパスをコピーしてください。 $ which git VScodeを開き、「①設定」に遷移し、「②git path」と検索、「③settings.jsonで編集」をクリックしてください。 編集画面にて以下のコードを追加します。パスの部分には先ほどターミナルでコピーしたご自身のものをペーストしてしてください。 settings.json "git.path": "/usr/bin/git" 以上で完了です。お疲れ様でした。

現場ではSubVersionを使っており、gitはちょろっと触ったことがあったのみ。add→commitを繰り返して適度にpushしてpullリクエストを投げて、コンフリクトを起こしたら慌ててググるみたいな状態だったので、ちゃんと勉強しようと思った。 Gitの本質はcommitだ、というのはなんとなく知ってはいたものの、それがどういうことなのかきちんと理解していなかったので自分の知識定着も兼ねて記事にしておく。 まだまだ初心者なので、間違いがありましたらご指摘いただけると嬉しいですm(_ _)m commitは差分ではなくその時点のスナップショット 1.ワークツリーの変更分のみをgit add、git rmし、インデックス(ステージング)環境に反映 2.インデックスの内容をローカルリポジトリにcommit という流れだからか、commitは変更差分だと思いがちだが、実際はインデックス環境のスナップショットを丸ごと取得している。 なので、後からcommitのSHA-1(commitした時に割り振られる長いやつ)を指定して前のバージョンに戻すことができる。 branch=ただのポインタ 上記のとおりcommitすると、そのcommitを特定するためのSHA-1が割り振られる。 なので繰り返しになるが、SHA-1が分かっていれば特定のcommit時のスナップショットを取り出すことができる。 ただSHA-1は暗号学的関数というだけあり、長すぎて覚えられない。というか、そもそも覚える目的で作られていない。 これでは頻繁に確認したかったり、別に分けておきたかったりするcommitがあったとき、いちいちgit logでSHA-1を確認しなければならず面倒。 そこで、覚えておきたいcommitを指すポインタを作り、自由に名前をつけれるようにしたのがbranch。 ここで注意が必要なのは、SHA-1 != branchだということ。 SHA-1はあくまで特定のcommitと1対1になっており、生成されたSHA-1が指すcommitは不変。 branchはあるcommitを親とした子commitができた場合、子commitを指す。ポインタなので位置が変わる。(変えられる) 1.コミット1が親のコミット2を作り、コミット2を起点とたdevブランチを作った場合 devブランチとHEAD(＝現在地)はコミット2を指す。 2.上記devブランチにコミット3を追加 コミット2に対するSHA-1は変わらず、devブランチとHEADの指す位置がコミット3に変わる。 今までbranch操作はちょっとヒヤヒヤしていたが、正体はポインタなので操作ミスをしてもまた新しいブランチを作れば良い。 それよりもcommitの変更内容がわかるようなコメントをちゃんと書くことの方が大切だと思った。 鬼門checkout checkoutはbranchを切り替えるときも使うし、編集したワークツリーを変更前の状態に戻すときも使うし、単語の意味をひくと「勘定を済ませて出ていく」とあるし、で、イマイチよく分からないコマンドだった。 しかし上記を踏まえると、checkoutはcommitせずにHEAD(=現在地)の位置を移動させるコマンド、という認識で良いのかなと。 branchの切り替え devブランチからmainブランチへcheckoutすると、mainブランチが指すコミットbにHEADが移動する。 ワークツリーの変更を戻す(インデックスの状態にする) 左　：ワークツリーとインデックスは同じコミットを指しているが、ワークツリーのほうは変更を入れてしまっている。 中央：そこでcheckoutし、インデックスのコミットを指し直す 右　：すると変更がリセットされ、変更前のコミット3の状態に戻る 参考 特に@JugglerShu@github さんの以下の記事はとても参考になりました。より詳細の情報が解説されており、実践形式で手を動かしながらできるので、Git初心者の方と先にSVNに慣れている方には特におすすめです。 https://github.blog/jp/2021-01-06-commits-are-snapshots-not-diffs/ https://ejje.weblio.jp/content/checkout

概要 新規に作業ブランチを切ったらブランチ名を打ち間違えていたことに気づいたとき、その場ですぐにローカルのブランチ名を変更できます。 ただし、リモートにプッシュ済みのブランチは変更してしまうと他の作業者に影響が及ぶので慎重に行いましょう。 ブランチ名の変更 # 作業ブランチを作成 git checkout -b feature/create-bugs # あっブランチ名まちがえた！ git branch -m feature/create-bugs-life

ローカルにワーキングディレクトリを作る mkdir [ワーキングディレクトリ名] ワーキングディレクトリに移動する cd [ワーキングディレクトリ名] ワーキングディレクトリを初期化する git init gitで紐づけたいリモートリポジトリを作成する。この時にREADMEファイルは作らずに、後から作成する。 gitで作成した新規のリモートリポジトリのURLを、以下のコマンドに貼り付ける git remote add origin [新規のリモートリポジトリのURL] ワーキングディレクトリにリモートリポジトリに作成したい、ファイルを作成する 作成したファイルをステージにaddする git add '[作成したファイル]' 作成したファイルをcommitする git commit -m '[付けたいコメント]' 作成したファイルをpushする git push origin main これでデフォルトのリモートリポジトリ(ここではmain)に対象のファイルが追加される 補足 1. 対象となるローカルのワーキングディレクトリに、リモートブランチと紐づけたいディレクトリ作成する。新たなワーキングディレクトリの名前は、これから紐づけるリモートブランチ名と一緒だとわかりやすい。 mkdir [リモートブランチ名] 作成したワーキングディレクトリに移動 cd [ワーキングディレクトリ名] ローカルのワーキングディレクトリに、新たにリモートブランチを作る git checkout -b [リモートブランチ名] ワーキングディレクトリにリモートブランチに作成したい、ファイルを作成する 作成したファイルをステージにaddする git add '[作成したファイル]' 作成したファイルをcommitする git commit -m '[付けたいコメント]' 作成したファイルをpushする git push origin [リモートブランチ名] これでリモートブランチと、そこに新規で作ったファイルが追加される

ソースはこちら GitHub shredded_push ここから下は日記です この記事にたどり着いた大抵の方は上の2行で目的を達せられると思うので ここからは日記レベルの内容です。 いきさつ 今回のシェルを作るに至った経緯ですが 運用中のシステムの移行に伴いいろいろと手直しが発生するので 一旦、画像含めサーバ上の物を全部Gitに乗せることになりました。 が、膨大な量の画像ファイルを一度にコミットしたところ容量なのかなんなのか プッシュがうまくいかず、ばらしてコミットしようと思った。 (LFSは使ってます) ググってもそれらしいツールも見つからず 昼飯食いながら作ったのが今回のスクリプトです。 いいわけ 正直中身は微妙だと思うし効率的でないコードです。 たぶん、1ファイルずつaddするより一度に複数ファイルaddした方が早い。 最後に 大量の更新が見込まれる画像ファイルとかの扱いって皆さんどうされてるんだろう、、、 私は手動で何かするとミスしかしないので 変更かけたファイルを保存時に別のファイルに上書き保存とか やりまくりそうだから管理用のツールがいいかと思いましたが 容量めちゃくちゃ食うのでGitに画像を大量に乗せるのは良くない気がしている。 この記事自体はおんなじように大量のファイルをバラシてでもコミットしたい人の目に留まればと思い作成したので 技術的な参考資料ではないです。 こんなところまで読んでいただきありがとうございました。

error: RPC failed; curl 92 HTTP/2 stream 0 was not closed cleanly: PROTOCOL_ERROR (err 1) とでた。 色々試してみて、解決できたので記録しておきます。 1. http/1.1へ変更 shell git config --global http.version HTTP/1.1 2. Gitの更新 shell #Macの場合 brew update #Ubuntuの場合 sudo apt update 他の記事さんでは、上の方法が記載されていたが、自分の方では解決できなかった。 解決した方法 ファイルのサイズが大きかったので、変更のあるファイルをフォルダの外に出して、バラバラにpushした。 shell cd git_dir #folder1を外に出す。 mv folder1 ../ git add . git commit -m "folder2" git push #folder1を戻してもう一度push。 mv ../folder1 . git add . git commit -m "folder1" git push 解決するときに参考にしたサイト backlogヘルプセンター