アカウント名:
パスワード:
常に最新バージョンをサーバーに置くことのできるWebアプリだからということは最低限必要な条件だと思う。
出荷済みの複数のバージョンのアプリがあって、それぞれにバグフィックスをしていけば、自然とブランチが増えていく。
とはいえ、Webアプリでもブランチ使ってる所は多そうだけどな。
出荷済みの複数のバージョンのアプリがあって、それぞれにバグフィックスを していけば、自然とブランチが増えていく。
そういう意味では, 顧客が1つしかない社内向けシステムでブランチが無いのは自然ですね.
# 事業部が違えば別会社も同然なんてとこもあるけど
全然自然じゃない。現行版の保守ブランチと次期版のブランチとって感じでやっぱり使う場合は使う。
保守ブランチは必要になったときに作ればいいから、都度作る必要はないです。次期版はHEADで行うとして、次期版の開発期間が十分短い、かつ何度も更新を繰り返すなら、自然とHEAD一本になるかと。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stableって古いって意味だっけ? -- Debian初級
Webアプリ (スコア:2, すばらしい洞察)
常に最新バージョンをサーバーに置くことのできるWebアプリだからということは
最低限必要な条件だと思う。
出荷済みの複数のバージョンのアプリがあって、それぞれにバグフィックスを
していけば、自然とブランチが増えていく。
とはいえ、Webアプリでもブランチ使ってる所は多そうだけどな。
Re: (スコア:1)
そういう意味では, 顧客が1つしかない社内向けシステムでブランチが無いのは自然ですね.
# 事業部が違えば別会社も同然なんてとこもあるけど
Re: (スコア:1)
全然自然じゃない。
現行版の保守ブランチと次期版のブランチとって感じでやっぱり使う場合は使う。
Re:Webアプリ (スコア:2)
保守ブランチは必要になったときに作ればいいから、都度作る必要はないです。
次期版はHEADで行うとして、次期版の開発期間が十分短い、かつ何度も更新を繰り返すなら、自然とHEAD一本になるかと。