アカウント名:
パスワード:
常に最新バージョンをサーバーに置くことのできるWebアプリだからということは最低限必要な条件だと思う。
出荷済みの複数のバージョンのアプリがあって、それぞれにバグフィックスをしていけば、自然とブランチが増えていく。
とはいえ、Webアプリでもブランチ使ってる所は多そうだけどな。
出荷済みの複数のバージョンのアプリがあって、それぞれにバグフィックスを していけば、自然とブランチが増えていく。
そういう意味では, 顧客が1つしかない社内向けシステムでブランチが無いのは自然ですね.
# 事業部が違えば別会社も同然なんてとこもあるけど
全然自然じゃない。現行版の保守ブランチと次期版のブランチとって感じでやっぱり使う場合は使う。
保守ブランチは必要になったときに作ればいいから、都度作る必要はないです。次期版はHEADで行うとして、次期版の開発期間が十分短い、かつ何度も更新を繰り返すなら、自然とHEAD一本になるかと。
> 次期版のブランチ
これは幹(HEAD)じゃないの?
次期版の内容が盛りだくさんだと、スケジュール通りにならない場合もあるので、分けたほうがよいです。まぁ別コメにもらったように内容次第ではHEAD一本で十分なので、そのほうが面倒がなくてよいですが。要は「顧客が1つしかない社内向けシステム」だからブランチがないのが自然ではなくて、「これか何をするか」でブランチを作ったり作らなかったりするのが自然かと。
Webアプリ。現在branch 2本。コミット履歴に記入して、その後リリース申請書を書いて申請書チェックツールを噛まして、さらにチェックリストおよび修正前後のエビデンス等々を格納し…。
ちなみに本番稼動前。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson
Webアプリ (スコア:2, すばらしい洞察)
常に最新バージョンをサーバーに置くことのできるWebアプリだからということは
最低限必要な条件だと思う。
出荷済みの複数のバージョンのアプリがあって、それぞれにバグフィックスを
していけば、自然とブランチが増えていく。
とはいえ、Webアプリでもブランチ使ってる所は多そうだけどな。
Re:Webアプリ (スコア:1)
そういう意味では, 顧客が1つしかない社内向けシステムでブランチが無いのは自然ですね.
# 事業部が違えば別会社も同然なんてとこもあるけど
Re:Webアプリ (スコア:1)
全然自然じゃない。
現行版の保守ブランチと次期版のブランチとって感じでやっぱり使う場合は使う。
Re:Webアプリ (スコア:2)
保守ブランチは必要になったときに作ればいいから、都度作る必要はないです。
次期版はHEADで行うとして、次期版の開発期間が十分短い、かつ何度も更新を繰り返すなら、自然とHEAD一本になるかと。
Re: (スコア:0)
> 次期版のブランチ
これは幹(HEAD)じゃないの?
Re:Webアプリ (スコア:1)
次期版の内容が盛りだくさんだと、スケジュール通りにならない場合もあるので、分けたほうがよいです。
まぁ別コメにもらったように内容次第ではHEAD一本で十分なので、そのほうが面倒がなくてよいですが。
要は「顧客が1つしかない社内向けシステム」だからブランチがないのが自然ではなくて、「これか何をするか」でブランチを作ったり作らなかったりするのが自然かと。
Re: (スコア:0)
Webアプリ。現在branch 2本。
コミット履歴に記入して、その後リリース申請書を書いて申請書チェックツールを噛まして、さらにチェックリストおよび修正前後のエビデンス等々を格納し…。
ちなみに本番稼動前。
Re: (スコア:0)
パッケージソフトウェアでバグフィックスにブランチ切る必要をなくす魔法の言葉