もっと見る
のえる :cava_red: DTP鯖管 さんがブースト

master ベースにしたいけどオリジナル機能のメンテした時にデプロイするぞってなった時未検証なコミットが一杯混ざるのが辛いんだよな

のえる :cava_red: DTP鯖管 さんがブースト

自分のブランチにmergeしてくの、アップストリームをmasterにしてるから楽なのかもしれない。タグをmergeしてくとコミットが巻き戻ったりあるかもだね。

のえる :cava_red: DTP鯖管 さんがブースト

@noellabo うちだと best-friends ブランチを当時の最新から切ってて、そこにうちの変更と v*.*.* を merge していく形を取ってます。大体今の所上手くいってるし行ってきたけど、 v2.8.0 の時は Mastodon 側が master からの前進じゃないブランチ採用してたので rebase 起こって困ったりしましたね……

まず、誰かが公開してくれた便利な改造だけど、一回cherry-pickなりmergeなりするじゃん?

次の本体のリリースが来た時に、コンフリクトするワケですよ。

で、ちょっと落ち着いたら対応版を出してくれる。よし、適用しよう! ……どうやって?

--

自分でいじったコード、まぁcommitしておきますよね。で、master追従したり、次のリリースをmergeしていく。

まぁたまにコンフリクトするから直す。

これ、何回かやっているウチに最初のコミット埋もれちゃってて、あとでそこだけ取り出して別のリポジトリ(誰かにあげるとか、自分で別のサイト立ち上げるとか)に適用しようと思った時に、すごく扱いづらくなりませんか?

Github上でプルリクにしとけば拾える? どこからどこへやればいいんだろう……。

スレッドを表示

攻撃対象をみつけて晒し上げるためのまとめサイトじゃなくて、

知見が集まった一連の投稿を共有するためのまとめ、あってもいいと思うんだけど、決め手がない。

俺の人生みたいだな(ここで使うフレーズじゃありません)

のえる :cava_red: DTP鯖管 さんがブースト
今は活発じゃないけどイメージとしてはpawoo.netのブランチ設計は参考になるとこあるんじゃないかな

こういう、わりとみんなが興味ありそうな話題だというのに、エアリプばかり。

言及を収集するとなると大変だし、みんなお互いのコメント読めなくてみんな不便じゃないの?

これってトリビアになりませんか?

スレッドを表示
のえる :cava_red: DTP鯖管 さんがブースト

@noellabo 弊ぼっちインスタンスではブランチで独自改造とアップストリームからの更新を混ぜてます。

ブランチへのpushでHerokuがステージングアプリにデプロイして、ざっと動作確認してからプロダクションアプリにpromoteするようにしてます。アップストリームへの追随はfetchしてmergeしてpush gist.github.com/zunda/2189218d 、独自改造はブランチ上で変更してpushするか、ブランチへのプルリクエストを作ってmergeすることになります。

のえる :cava_red: DTP鯖管 さんがブースト
開発のためのフローは本当に効率化して機能の追加をしやすくする指針だからちょっとしたコード変更を公開したり維持するのもやっぱりそれを意識した方が楽

機能ごとにブランチ切るのはどれをどこまでやったかみたいなことを明確にするので…
いろんな変更をごちゃ混ぜにしながら一つのブランチで維持するのはとっ散らかるだけだからその雰囲気のフローは消耗しそう
のえる :cava_red: DTP鯖管 さんがブースト
貢献するときは自分用のmainブランチは要らんからfeatureブランチとか切ってるけど
のえる :cava_red: DTP鯖管 さんがブースト
本流の開発に貢献せずに追従していくときはだいたいこれ
のえる :cava_red: DTP鯖管 さんがブースト
追加した機能や変更のブランチ名を切って自分用のmainブランチへマージ(GitHubのPRとかGitLabのMRで番号つけて管理すると楽?)してからバージョン上がる度にmainブランチへマージするのが普通にわかりやすいフローだと思うんだけど
のえる :cava_red: DTP鯖管 さんがブースト
普通にpatchブランチか自分の適用するドメインのブランチ切ってupstream/masterとかorigin/masterとかマージしていけばいいのでは

Mastodonにしても、PleromaもMisskeyもみんなそうだけど、gitで最新版のソースをとってくるじゃん? 運用のために。(開発じゃなくて)

で、.gitignoreで管理対象外にしてある設定ファイルはともかく、やっぱりちょっとソースコードいじることあると思うんだけど、いじった時に、それをどのように公開したり、維持していったらいいか、こうやればいいよ!ってのある?

GitFlowとかGithubFlow、GitLabFlow、みんな開発のためのフローなのよね。

圧倒的な物量の本家の開発成果を利用し、更新に追従しながら、どこかから借りてきた改造と、自分のあてた小さなパッチ(コミット)を維持していくだけのフロー、だれか提案してない?

(私も色々考えてやっているけど、再発明してもしょうがないので)

Web上の記事でもそうだし、枠の小さい雑誌の紙面などではますますそうだけど、そもそもどこかを参照しないで自分で全部書き下せるということはないので、必ずどこかを参照先として提示しないといけないのだが……

Mastodonのサーバはいろいろあります、ここをみて下さい!ってjoinmastodon.org紹介しても、正直、覗きにきた人、帰っちゃうよね……。

スレッドを表示

鯖缶びちびち(陸に上がって、やがて動かなくなった者も……)

Acrobat、ビジネスユーザーにとってアであるというのに、DTPユーザーにとってもアであって、担っている役割の割に、鬼っ子なのだ。

あやつ、DTPクラスタから見ると、PDFを編集できます!とか言い出す、最大の裏切り者であるw

たのむ……やめてさしあげろ……。

結局、参照先が頼りないという問題があるな。

マストドン日本語ウィキは鉄板として、他が弱い気がする。

joinmastodon.orgは、日本など各国のローカルな事情をカバーするより、グローバルでどこでも同じ体験ができます!ってのがウリだから、なかなか難しいところがある。

docs.joinmastodon.orgも、充実している方ではあるが、プルリクは放置するし、まだみんなgithubにあるドキュメントを参照しちゃったりする有様で、これもなんとも頼りない。

のえる :cava_red: DTP鯖管 さんがブースト
のえる :cava_red: DTP鯖管 さんがブースト
もっと見る

のえる :cava_red: DTP鯖管 によるおすすめ:

DTP-Mstdn.jp

DTP-Mstdn.jpは、DTP・デザイン・印刷に関わる人々のためのMastodonインスタンスです。特定分野の専門インスタンスですので、日々のつぶやき、耳寄りな情報の共有、ディスカッション、質問とその回答、役立つスクリプトなど、他では投稿しづらい内容も、思う存分トゥートしましょう!