2017-03-04 11 views
1

これは重複している可能性がありますが、リリースの作成についてGitHub help pageを行った後、私が探しているものが見つかりませんでした。gitでリリースするコンテンツを選択する

私はgitをしばらく使っていましたが、masterの内容の一部を共有する準備ができている状況がよくありますが、まだ洗練され、さらにテストされたり、リファクタリングされたりする必要があります。新しいブランチを作成して、まだリリースしたくないものを削除することはできますが、それでも履歴は保持されています。次のバージョンでは、新しいコンテンツのサブセットと一緒に改善をマージすることはできません。基本的に新しいブランチを毎回始める。

私が本当にやりたいことは、リリースされる準備ができているフォルダやファイルを選択し、これらのファイルの関連履歴のみをフィルタリングし、この新しい履歴の上にリリースに含まれていないコンテンツをリベースすることです。私はこれが "書き直しの歴史"の一形態であることを認識していますが、gitでこれを行う方法はありますか?そうでない場合は、関連する履歴を持つリリースを作成し、後でマージできる「適切な」方法は何ですか?

+1

"関連する履歴を持つリリースを作成し、後でマージすることができます"。それは事実上ブランチの定義です。私は、すべてのリリースで分岐することに対する懸念を理解していません。 –

+0

リリースブランチでリリースされていない作品の履歴が欲しくない理由を聞かせることはできますか? – oyvind

+0

@oyvindあなたとマットは、それが実用的な違いはないという意味で正しいと思いますが、私はそれをよりきれいに感じるでしょう。何かをトリミングする方法があれば、指定されたファイルのサブセットと無関係で、この新しい履歴の上に選択されていない内容を再配置します。また、特定のリリースのタグを振り返ってみると、より明確になります。 – Sheljohn

答えて

1

もっとも簡単な解決策は、おそらく別のreleaseブランチに、公開するファイルが入っているブランチを保持しておき、おそらくselectively merge in the files you want changed from masterです。こうすることで、変更したい特定のファイルだけが実際に更新されます。

1

git filter-branchをサブディレクトリフィルタとプルーン空スイッチで試してみてください。それは非常に侵略的なコマンドであるので、あなたが何をしているのかを確認してください。全マンページhttps://git-scm.com/docs/git-filter-branchを読んでください。

残りの履歴を一番上に置いている限り、あなたの歴史が非常に短い場合を除き、紛争の数はまったく禁止されていると思います。また、主要な開発ブランチのリベースについて話している場合は、開発者が新しいバージョンをそれぞれのローカルクローンに引き込む際に問題を引き起こします。

+1

ありがとう、私は、チェリーピッキングを新しいブランチに(以下のスティーブンの答えで示唆されているように)、リリースを作成する最も優れた最も一般的な方法かもしれないと思います。 [this post](http://stackoverflow.com/a/5968622/472610)の最後の図は、gitでの典型的なプロジェクト開発を示しています。実際にはこれは整然としたものだったと思いますが、進捗。 :) – Sheljohn

+0

リリースブランチのファイルを排除するのはよくあることではありません。これらの部分的なリリースがどのように見えるかについてもう少し言えば、もう少しお手伝いできます。おそらく、部品を独立してリリースする場合は、別々のreposや、各部品のリリースブランチを別々にする方がよいでしょう。各ブランチに対して、リリースするものが分かっているので分かりません。リリーススクリプトで多くのことを解決できます:-) – oyvind

関連する問題