6

私は自分のグループにセマンティックバージョニングを使用してgitに移行するように説得することができました（すべての開発がトランクで行われたCVSから）。

これは私たちが少しの間使用してきたものです（バージョンブランチはある種の新機能の導入を示しています）：

master
*
|
*   * version 2.0 branch
|  /
* *
|/
*   * version 1.0 branch
|  /
* *
|/
*
|
...

問題は、バージョン1.0ブランチで行う必要のあるバグ修正がある場合、その修正をバージョン2.0とマスターにエコーアップする必要があることです。私たちはさくらんぼを選んでいますが、それは私が望むよりもエラーが発生しやすいように感じます（そして時間が経つにつれてそれは手に負えなくなるだろうと感じています）。

私たちが行っていることにはいくつかの制限があります-それはレガシーコードであり、行われているテストは多くありません（ユニットテストの導入を開始し、統合テストはほとんどありません）ので、それらのバージョンブランチの安定性を維持します（導入しない多くの回帰エラー）が重要です。

さくらんぼ狩りよりも、これにアプローチするためのより良い方法がありますか？使用するより良いワークフローはありますか？あなたが提供できるどんな助けにも本当に感謝しています。

4

1 に答える 1

5

チェリーピッキングは次のことができます。

私はマージを好みます (これは、 Desert69で言及されている成功した Git ブランチ に似ています):

  • その専用のブランチを作成しますbuxfix_xxx（version1の上に）
  • version1 をそのブランチにマージしますbuxfix_xxx(早送り)
  • マージbuxfix_xxxしversion 2てmaster分岐する

もちろん、すべてのファイルを実際にマージせずに、これらのブランチ (バージョン 2 とマスター) でマージを記録するのがコツです。

マージするファイルが数個しかない場合は、次のようにします。

# make git believe we are merging everything
git checkout version2
git merge --no-commit bugfix_xxx

# but reset everything to version2
# (while the merge is still in progress!)
git checkout version2 -- .

# merge only the few files we need:
git checkout --patch bugfix_xxx -- path/to/file1
git checkout --patch bugfix_xxx -- path/to/file2
git checkout --patch bugfix_xxx -- path/to/file3

# add and commit, concluding the merge

これらのマージの良いところは、次のもの ( version1toversion2と から) は当然次のバグ修正に限定されることです。なぜなら、git は他のすべてが既に mergemasterであると信じているからです!

したがって、バグ修正の最初のバックポートに投資した時間は、次のバグ修正のために支払われます。

于 2013-03-09T09:37:43.917 に答える