のえる DTP鯖管 @noellabo@dtp-mstdn.jp

submoduleは別のトラブルを生みがちな印象があって敬遠しがち

タグのマージはなぁブランチ違えばcherry-pickのrebase混じりになるからしんどいだろうなぁ…うーん

ブーストウォッチ、本当は投稿そのものを取りたかったんだけど、作った当時はAPIアクセスしか使っていなくてActivityPubなんもわからん状態だったので、他サーバの投稿をとる方法が無くてこんな感じになってしまった。

boostwatch、リンクじゃなくて実際のBT先トゥートまで表示されてれば完璧なんだけども

いうのが私の運用だけどremoteが複数あると管理めんどくさいところあるかもなぁみたいな

upstreamをわざわざmasterに取っておく意味はあんまりないと思うからremoteにupstream追加してgit fetch --allすればいいかなぁって

動かす用ブランチを生やして、そっからrebaseしていく方針
mergeしていくともうわけわかめになっていって面倒すぎて

git rebase は PR する時とか feature- ブランチとかで 1 コミットにまとめておきたい時くらいしかまだ使っていない（他の使い方を知らない

ブランチ名について：
upstream_master：本家をリモートリポジトリとして追加したもの
master：自分のリポジトリのmaster
crazynewworld：弊鯖の独自変更のブランチ

コマンド：
git checkout upstream_master
git pull
git pull --tags
git checkout master
git merge upstream_master
git push origin master
git push origin --tags
git checkout crazynewworld
git rebase master

ここでコンフリクトがあったら該当ファイルを修正して、
git add <修正したファイル名>
git rebase --continue

rebaseが通ったら、例によってbundle updateとかやーんとかmigrateとかprecompileとかリスタートとかやって、最後に

git push -f origin crazynewworld

github 上で指差し PR はやりますね……あれなんで最初は必ず本家向いちゃうの……

指差し git 割とやる
history 打って手順ちゃんとやったかの確認も

gitのrebase、よく理解してなくて歴史を改竄するときにしか使っていない。

pull -f的なやつ、コンフリクトでresetもなんかエラー出るみたいな時があって、別のブランチを作ってそっちに切り替えたあと、masterブランチを消して、originからmasterを取り直す。ということをしたことがある。

バージョンアップ追従の時は、current-foresdon から生やしたバージョンアップ用 branch に merge v2.8.2 とかして、1回テスト鯖をその branch でひととおり動かしてみてから、運用 branch に merge してますね♪