Gitブランチから機能を一時的に削除する

Question

gitを使ってアプリケーションのコードリポジトリを管理していますが、まだ遭遇している状況がありますが、非常に一般的です。

フィーチャを一時的に削除してから、ある時点でフィーチャを追加したいと考えています。私はこれをサポートする分岐構造を想像しようとしています。あるいは、コードからフィーチャーを取り除くだけの簡単なことをしなければならない場合は、コミット履歴から再作成してください。

誰でもこの状況を適切に処理できるかどうかを指摘できますか？

Answer 1

Gitリポジトリ履歴よりも前の機能を一時的に削除する方法の1つは、機能を削除するコミットです。その後、フィーチャーを追加したいときは、単純にrevert the commitを取り出してください。あなたは簡単にして、機能を後から再度追加することができていることを確認したい場合

git revert <sha of commit that removed the feature> 

：これは、それが効果的に機能を再度追加します逆の変化を、適用される意味、逆パッチを行いますその間にコードの変更と同期して、別のフィーチャブランチを削除した直後に作成し、そのブランチを他のフィーチャブランチと同じように扱い、頻繁に再配置することで、そのブランチをmaster（それがあなたのやり方であればdevelopブランチ）、あなたが行っているように衝突を解決してください。

GitHub FlowまたはGit Flow分岐戦略を使用している場合は、基本的には機能ブランチの概念を使用して、 。開発のラインを簡単にするために、私は）この例ではGitHubのフローを使用します：

# 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 

を頻繁master（またはdevelopと同期してsaved-featureを守ってきたと仮定すると、それはあなたが使用するものの場合）、などの競合を解決しますあなたは、機能を元に戻すことに問題はないはずです。

参照用ドキュメント：[？どうやってマスターとは別のブランチにコミットのセットを移動することができます]

• Rebase
• Revert
• Merge

Answer 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つのフルコミットツリーがあるため、フィーチャがプロジェクトに再接続するすべてのポイントが存在することがわかります。それで、プロジェクトに戻すために必要なものすべてを手に入れることができます。これは私の場合に起草するものです。幸運、人。

Answer 3

私はこれをコード自体で解決します。フィーチャーマップ（基本的に各機能のブール値フラグ）を追加し、リポジトリからコード/ロジックを実際にリッピングすることなく、必要に応じて機能を有効/無効にします。

ような単純な設定ファイルに何か：

<?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(); 
     } 
    } 
} 

注：上記は半擬似コードである、あなたの対応するコントローラで

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

そして。

Answer 4

はここ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のすべてプラス機能の回復を（a122936コミット）が含まれています。prodで新しいコミットを作成すると、それらはrestore-bにマージされるので、その機能を復元する準備ができたらいつでも簡単に早送りマージできます。

より単純なアプローチは、機能を復活させる準備ができている時点まで、a112936コミットとrestore-bブランチを作成しないようにすることです。 restore-bブランチを作成して最新の状態に保つことの利点は、他の変更との矛盾が適時に（矛盾するコードを書いた開発者がうまくいけば、書いた直後に）うまく解決されることです。これにより、機能が「新鮮」かつ「オンデッキ」に保たれ、追加の開発作業を必要とせずにプロダクションリリースに組み込む準備が整います。