DTP鯖管
Mastodonにしても、PleromaもMisskeyもみんなそうだけど、gitで最新版のソースをとってくるじゃん？ 運用のために。（開発じゃなくて）
で、.gitignoreで管理対象外にしてある設定ファイルはともかく、やっぱりちょっとソースコードいじることあると思うんだけど、いじった時に、それをどのように公開したり、維持していったらいいか、こうやればいいよ！ってのある？
GitFlowとかGithubFlow、GitLabFlow、みんな開発のためのフローなのよね。
圧倒的な物量の本家の開発成果を利用し、更新に追従しながら、どこかから借りてきた改造と、自分のあてた小さなパッチ（コミット）を維持していくだけのフロー、だれか提案してない？
（私も色々考えてやっているけど、再発明してもしょうがないので）
まず、誰かが公開してくれた便利な改造だけど、一回cherry-pickなりmergeなりするじゃん？
次の本体のリリースが来た時に、コンフリクトするワケですよ。
で、ちょっと落ち着いたら対応版を出してくれる。よし、適用しよう！ ……どうやって？
--
自分でいじったコード、まぁcommitしておきますよね。で、master追従したり、次のリリースをmergeしていく。
まぁたまにコンフリクトするから直す。
これ、何回かやっているウチに最初のコミット埋もれちゃってて、あとでそこだけ取り出して別のリポジトリ（誰かにあげるとか、自分で別のサイト立ち上げるとか）に適用しようと思った時に、すごく扱いづらくなりませんか？
Github上でプルリクにしとけば拾える？ どこからどこへやればいいんだろう……。
@noellabo 弊ぼっちインスタンスではブランチで独自改造とアップストリームからの更新を混ぜてます。
ブランチへのpushでHerokuがステージングアプリにデプロイして、ざっと動作確認してからプロダクションアプリにpromoteするようにしてます。アップストリームへの追随はfetchしてmergeしてpush https://gist.github.com/zunda/2189218dbf77e7f22c99094c567813a5 、独自改造はブランチ上で変更してpushするか、ブランチへのプルリクエストを作ってmergeすることになります。
@noellabo うちだと best-friends ブランチを当時の最新から切ってて、そこにうちの変更と v*.*.* を merge していく形を取ってます。大体今の所上手くいってるし行ってきたけど、 v2.8.0 の時は Mastodon 側が master からの前進じゃないブランチ採用してたので rebase 起こって困ったりしましたね……
@rosylilly 私はまさらっきさんのmastodon本とgit本を参考にしてきたので、
開発用のnoellabo/mastodonと、サーバ公開用のdtp-mstdn-jp/noellaboにわかれてて、
noellabo/mastodonの方にfeatureブランチとかmerge用のブランチ作って、dtp-mstdn-jp./mastodonのdtp-mstdn-jp（デフォルトブランチ）にプルリクする運用を続けています。
ただ、2年やってきてかなり秘伝のタレになっていて、昔のコミットが今のコードに使えなくなってます（抽出するのが大変）。
--
最近、常に本家のタグリリースからブランチ生やして、自分の適用した変更を末尾にぶら下げたい（rebaseですね）なと思うようになりました。
（ちょっとやってみてます）
ウチの適用してるコミットはこれです！って末尾をみてもらえばいいし、いつでも最新版にマージできる状態でメンテしておける。ヨソ様のパッチも、改めて最後に追加する方が楽なのです。
master追従するときはrebaseしてます。
@noellabo そうすよね。昔のパッチ追うのが大変なんですよね……
こういう、わりとみんなが興味ありそうな話題だというのに、エアリプばかり。
言及を収集するとなると大変だし、みんなお互いのコメント読めなくてみんな不便じゃないの？
これってトリビアになりませんか？