- Gitをより良くするための運用ガイドライン作成スレ [転載禁止]©2ch.net
143 ：デフォルトの名無しさん[sage]：2015/07/02(木) 20:35:15.89 ID:E2OQ2sTs - >>138
オープンソースの例ではないが、業務上でありそうなものとしてはモジュール毎に担当者が決まっていて
1) 共通APIに機能を追加するために引数追加
2) それを使用している他のモジュールで引数追加に対応
で、1と2で担当者が違うから別々のコミットにしたい場合とか。
|
- Gitをより良くするための運用ガイドライン作成スレ [転載禁止]©2ch.net
144 ：デフォルトの名無しさん[sage]：2015/07/02(木) 20:48:20.71 ID:E2OQ2sTs - merge --no-ff必須にしておけば、mergeコミットは必ずコンパイルもテストも通る、って運用は可能だと思う。
pushする前にはコンパイル確認必須、とした場合も、masterブランチにコンパイル不可なコミットが混ざる可能性があるが、動作保証を自動テストで担保している場合はそれほど困らないんじゃないかな？
テストの方は全コミットで動作保証できることを期待してないだろうし、コンパイルに通らない事はテストに失敗したとみなせば同じ事だし。
|
- Gitをより良くするための運用ガイドライン作成スレ [転載禁止]©2ch.net
146 ：デフォルトの名無しさん[sage]：2015/07/02(木) 21:57:29.71 ID:E2OQ2sTs - >>145
>>>143
>ないな。新しいAPIを追加して前のものは残す。
>新しいAPIに乗り換えるよう通達して、参照がなくなったところで削除する。
各コミットのコンパイル可能を保証するために、その手順を踏むことが望ましいという主張だね。
俺だったら引数追加するたびにAPI名を変更するぐらいなら、squashでまとめるか、常にコンパイル可能を諦める方を選ぶな。
|
- Gitをより良くするための運用ガイドライン作成スレ [転載禁止]©2ch.net
147 ：デフォルトの名無しさん[sage]：2015/07/02(木) 22:01:33.42 ID:E2OQ2sTs - >>144
>そんな事してもcherry-pickで拾ったら不完全なものを取り込んでしまう。
cherry-pickが完全に取り込めるかは、そのときのHEADがコンパイル可能かどうかとは関係ないよね。
新APIを追加するコミット無しに、新APIを使うコミットは適用しても、コンパイル出来ないよ。
|