14

アプリのコード リポジトリを管理するために git を使用しており、まだ遭遇したことのない状況がありますが、非常に一般的だと思います。

機能を一時的に削除し、将来のある時点で再び追加したいと考えています。これをサポートする分岐構造を想像しようとしています。または、コードから機能を削除し、再追加す​​る準備ができたら、コミット履歴から再作成するだけの簡単なことを行う必要があるかどうかを考えています。

この状況を処理するという点で、誰かが私を正しい方向に向けることができますか?

4

4 に答える 4

11

Git リポジトリの履歴より前の機能を一時的に削除する方法の 1 つは、機能を削除するコミットを行うことです。その後、機能を再度追加したい場合は、機能を削除したコミットを元に戻すだけです。これはリバース パッチを実行します。つまり、変更が逆に適用され、機能が効果的に再追加されます。

git revert <sha of commit that removed the feature>

その間、コードへの変更と同期を保つことにより、後で簡単に機能を再追加できるようにしたい場合は、削除した直後に別の機能ブランチを作成し、そのブランチを処理するだけで済みます。他のフィーチャー ブランチと同様に、頻繁にリベースして同期を維持しmaster(または、developそうしたい場合はブランチ)、進行中に競合を解決します。

したがって、基本的には、このようなことをしたいと思うでしょう ( GitHub フローまたはGit フロー分岐戦略を使用している場合は大した問題ではありません。どちらも最終的にメインラインにマージされるフィーチャー ブランチの概念を使用します)。簡単にするために、この例では GitHub Flow を使用します):

# On master branch
git commit -m "Remove feature X" # Creates commit 1234567...

# Now make feature branch
git checkout -b saved-feature

# Immediately put the feature back in the feature branch
git revert 1234567

# When you want to sync branch with master, just use rebase.
# Rebase allows you to sync frequently, since it doesn't
# leave behind a bunch of merge commits.
#
# From the feature branch:
git rebase master # Resolve any conflicts as needed.

# N commits later, you decide it's time to merge the feature
# back in.  You can use fast-forward or non-fast-forward merge,
# it's up to you.
#
# Using fast-forward merge with master checked out (assuming
# feature branch was just rebased onto master):
git merge saved-feature

# Or forcing a merge commit, if that's what you want:
git merge --no-ff saved-feature

saved-feature頻繁に とmaster(または、それを使用している場合は ) と同期を取り、競合を解決していると仮定するdevelopと、機能を元に戻す際に問題は発生しないはずです。

参考資料:

于 2013-07-10T03:56:22.330 に答える
2

これはうまくいくはずの戦略です。あなたの仕事はあなたのプロジェクトにかなり組み込まれているように思えます。最初に出発点を選択します。私にとっては、通常はdev分岐します ( もあると仮定しますmaster branch)。プロジェクトから削除される機能となる新しいブランチをスピンオフします

git checkout -b dev_feature_removed

また同時に、プロジェクトで維持される機能となるブランチのスピン。

git checkout -b dev_feature_sustained

次に、この機能が正しく完全に削除されていることを確認するために必要なコーディングとテストを行い、dev_feature_removedこれが事実であることを確認したら、そのブランチを本番環境にマージします。私の場合、さらにテストするために開発し、次にマスターに移行してライブに移行します。

その間、他のブランチdev_feature_sustainedもレポに保持できます。dev をこのブランチにマージして同期を維持し、削除された機能 (バグ修正または新しいベルとホイッスル) を dev にマージしてライブに戻す日に追加することもできます (私の場合、おそらくあなたのマスター）。

この機能の復帰により、機能がどの程度緊密に結合されているかによっては、マージの競合が発生する可能性があります。あなたのものはレポよりも前にあるので、マージ戦略ができることは限られているため、何があっても競合が発生するように思えます。ただし、2 つの完全なコミット ツリー (1 つは機能あり、もう 1 つは機能なし) があるため、機能がプロジェクトに再接続するすべてのポイントの存在を知ることができます。したがって、プロジェクトに戻すために必要なものがすべて揃っています。これは、私の場合に起草するものです。がんばれ、男。

于 2013-07-10T00:11:46.830 に答える
2

John Galt's answerの戦略を示す具体的な例を次に示します。

$ git log --graph --decorate --oneline
*   d1d201b (HEAD, restore-b) Merge branch 'prod' into restore-b
|\
| * 18d759f (prod) add feature e in prod
* |   191037e Merge branch 'prod' into restore-b
|\ \
| |/
| * e0de1be add feature d in production
* | a122936 Revert "remove feature b in production"
|/
* d3e2c42 remove feature b in production
* 5369ecf existing three features

基本的に、restore-b常にprod機能の復元に加えてすべてが含まれます ( commit a122936)。で新しいコミットを行うとprod、それらは にマージされるrestore-bため、機能を復元する準備ができたら、単純な早送りマージになります。

より簡単なアプローチは、機能を復活させる準備が整うまで、a112936コミットとブランチの作成を避けることです。restore-bブランチを作成して最新の状態に保つことの利点はrestore-b、他の変更との競合がタイムリーに 1 つずつ解決されることです (できれば競合するコードを書いた開発者が、それを書いた直後に)。これにより、機能が「新鮮」で「オンデッキ」に保たれ、追加の開発作業なしで製品リリースに含める準備が整います。

于 2013-07-10T03:39:11.450 に答える
0

私はこれをコード自体で解決します。機能マップ (基本的に各機能のブール値フラグ) を追加し、必要に応じて機能を有効/無効にするだけで、実際にリポジトリからコード/ロジックをリッピングする必要はありません。

次のような単純な構成ファイルの何か：

<?php
$features = array(
    'news' => true,
    'events' => true,
    'shop' => false
);

そして、対応するコントローラーで：

<?php
class ShopController extends AbstractController {

    public function __construct() {
        // $features array would be passed in somehow;
        // maybe via a dependency injection container
        if (!$features['shop']) {
            // feature is disabled, so just send 404 page for now
            throw new ResourceNotFoundException();
        }
    }
}

注: 上記は半疑似コードです。

于 2013-07-10T00:16:54.750 に答える