6

あなたの会社が社内で使用しているプロジェクトの git リポジトリをセットアップする最良の方法は何ですか?

Acme社に「supercoolproject」というレポがあるとしましょう。彼らはそれをオープンソースにしたいと思っていますが、実際には会社名をそれに関連付けることはまったく望んでいません。開発者の名前 (またはグループなど) のいずれかで GitHub アカウントを設定し、リポジトリを作成します。これを社内の Acme サーバーに複製します。「アクメ」はどこにも言及されていません。

ここで問題が発生します。どの組織にも、オープンソースを理解し、一部のコードを公開する権限を持つ開発者がいます。すべてのニュアンスを理解していない人もいます。これらのいずれかがコミットを行う場合、おそらく会社名やその他の機密情報が含まれます。または、内部的に元に戻すことができる恐ろしいコミットを行うだけです(履歴を書き換えるのではなく、「元に戻す」コミットを追加することについて話しているだけです)。しかし、これらの独自のコミットがオープン ソース ブランチに出ていくのは望ましくありません。

したがって、「acme_internal_{dev,qa,production}」ブランチと、外部の「マスター」ブランチ (およびその他のブランチ) を作成します。それらを同期させる最善の方法は何ですか? オープンソース リポジトリでのコミットを受け入れたい。そして、内部コミット (のほとんど) をプッシュしたいと考えています。でも出してはいけないものもあります。

悪いコミットを削除できないため、内部 -> 外部のマージは悪いことのようです。外部ブランチを内部ブランチにリベースすることはできますが、一度「git rebase -i acme/acme_internal_dev」を実行して履歴を変更すると (コミット メッセージの変更、コミットの削除など)、リベースできなくなるようです。 2つの歴史は分岐します。では、すべての内部コミットをパブリック ブランチにチェリー ピックしてから、パブリック ブランチを内部ツリーにマージすることになりますか? 内部で重複したコミットが発生するため、これも醜いように思えます (元のコミットと、外部に移動して内部にマージされた厳選されたコミット)。

この質問の目的のために、内部的に Acme が内部ブランチで履歴を書き換える (実際には悪いコミットを削除/変更する) ことを避けたいと仮定しましょう。

4

2 に答える 2

1

解決策は、厳密に制御された「外部から見える」リポジトリを用意することです。このリポジトリは、githubにプッシュアップする権限を持つ開発者のみがコミットできます。

内部リポジトリからのコードは、許可された開発者によって統合およびマージされることによってのみ、外部に表示されるリポジトリになります。つまり、許可されていない開発者は、パッチファイルを介して許可された開発者にコードを送信するか、パブリックリポジトリに対してリクエストをプルする必要があります。

はい、つまり、許可を得た人はすべてのパッチを確認して統合する必要があります。ただし、許可されていない開発者は信頼できないので、とにかくそうしてもらいたいと思います。

于 2012-06-04T17:29:43.310 に答える