2017-12-24 22 views
1

私は2つのブランチB(プライベート)とG(パブリック)を持っています。無関係なブランチ間のgit-mergeが不要なコミット履歴をインポートするのを防ぐ

ブランチB(プライベート)は私の主な開発ブランチであり、プライベートコード、独自のアルゴリズム、および公開できないその他のものを含むあらゆる種類のコミットを含んでいます。

ブランチG(public)を作成したときに、B(プライベート)から分岐することはできませんでした。これにより、以前公開されていないすべてのものが履歴に含まれるため、最初からブランチします(つまり、親なし)。その後、ブランチB(プライベート)からブランチG(パブリック)までのすべてのファイルを正確にインポート(コピー)し、それは最初のコミットでした。

それ以来、ブランチB(プライベート)で開発していて、新しいコミットが行われるたびに、G(公開)にチェリーピックアップしました。

これはすべて私がgitを始めていた時期に行われたので、私はおそらくこれをもっと良い方法でやったかもしれないことを知っていますが、この船は長く航海しています。

gitがどのように動作するのか(使い方について)もう少し学んだので、BG(あるいはその逆)にマージしたいので、毎回チェリーピックを止めることができました。

  1. GBのマージ:これは歴史のコミットへのアクセスを持っているでしょう「はGが閲覧誰がためunnaceptableであるS(プライベート)Gにコミット履歴、」はBのすべてを輸入だからここに私が試したものですプライベート/機密データ/アルゴリズム。

  2. GBへのマージ:これはG(プライベート)の上に桜摘みコミットのすべてを複製し、迷惑ではなく、大したことです。しかし、BGにマージしようとしてからまだ十分ではありませんでした。Bの(プライベート)コミット履歴のすべてをGにインポートしました(受け入れられません)。私はこれが、gitがBからGへの将来のマージの出発点として使用する2つのブランチに対して「共通の親」を作成すると思っていましたが、そうではありませんでした。 1. GのオフリベースB

  3. と同じ問題:Bのオフ

  4. リベースGごとにGにコミットするために、競合が作成されましたので、これは元に戻すことを証明しました。

TL; DR:私は2つの支店Bを持つプライベートで公開されている民間のコミットとGが含まれています。これは、彼らがどのように見えるかです:

 
`B` (private): a -- b -- c -- d -- m -- n -- o -- p 
`G` (public): w -- x -- y -- z -/ 

mBGからコミットマージです。

私が(単一のマージがもたらすコミットそれらを一つずつチェリーピッキングせずに、Gに「マージ」またはnopをコミット(および他のBにプッシュコミット)「をもたらす」、「輸入」したいですBの前回の履歴をすべて取り込んでいない限り、Gに変更しても問題ありません。

私の問題の解決策があるかどうかは分かりませんが、助けてください。

答えて

1

述べたように、真の機密情報はすべきではない/場合も、あなたの公開リポジトリへの外部貢献可能Gitリポジトリでは、いくつかのボールトにあります(Gitコンテンツフィルタドライバeven though that can be challenging)。

個別のGitリポジトリを持つことは最小であり、私的なものはパブリックを参照しますone as a submodule

+0

私はこれが行く方法だと思う、本当にサブモジュールを使用して考えていない、ありがとう! – Guaycuru

+0

私はサブモジュールについていくつかの読書をしました。いくつかの質問がありました:プライベートサブモジュールとして独自の/プライベートクラスを追加すると、公開リポジトリにアクセスする誰もがそのサブモジュールに関するエラーに直面していませんか?みんなが公的なレポをチェックアウトするのを妨げないだろうか? – Guaycuru

+0

@Guaycuruこれは私が書いたものです。私的なレポは、公共のものをサブモジュールとして参照します(追加します)。反対ではありません。 – VonC

2

これらのプライベートなコミットの性質は何ですか?それらは自分のファイルに自己完結していますか?あなたがコミットを選んだので、これが正しいと仮定しています。パブリックアルゴリズム/データ対プライベートアルゴリズム/データの性質のマージ競合を常に処理していないことを願っています。

代わりにブランチを使用せず、代わりに別のリポジトリを使用することをお勧めしますか?あなたのデータとアルゴリズムを保護することに気を配ったら、別のチームメンバーが間違って何かをリベース/マージするとどうなるか考えてみてください。また、ほとんどのgitサーバーはブランチレベルではなくレポレベルで動作するので、監査とアクセス制御は別のreposを使用するとはるかに簡単になります。

あなたは別のレポのために行くことに決めるならば、あなたの専有情報隠蔽のための2つの可能な解決策があります:環境/設定変数/秘密鍵などのような

  1. 秘密:これらは、バージョン管理にすべきではありませんとにかくシステム。 .gitignoreのラインでそれらを守ってください。それらをチームメートに渡す必要がある場合は、VCS以外の通信手段を使用してください。これにより、データを誤ってパブリックリポジトリにプッシュすることなく、一度のプッシュを可能にします。
  2. プライベートクラス/実装:これは難しいことです。あなたは明らかにそれらをgitignoreしたいとは思わない。私はおそらく私のチームがgit public-pushか何かをすることを可能にするためにgitプラグインを書くだろう。これにより、プライベートファイルを構成するプログラムをプログラムで決定することができ、パブリックリポジトリにプッシュする必要がないため、柔軟性が大幅に向上します。また、これについての不自由な人は、依然として監査とチェリーのコミットを選択できます。

TL; DR - 別のブランチの代わりに別のレポを持っていて、おそらくカスタムgitプラグインです。これにより、1つのgit push(またはカスタムプラグインgit public-pushか何かのために)を使用できるようになり、それが有名になったときに:)

+0

実際には、 'B'のリモートはBitbucketにあり、' G'のリモートはGithubにあります。それは分離レポとしてカウントされますか?とにかく、あなたは正しいと思います。別のリポジトリ(別のものをサブモジュールとして使うもの)は、おそらく行く方法です!ありがとう! – Guaycuru

+0

また、秘密鍵とパスワードはバージョン管理上の問題ではないため、ここで問題にはなりません。 ;) – Guaycuru

関連する問題