2

私のチームは過去数か月間、あるプラットフォームに取り組んでおり、会社の他のメンバーにリリースする準備ができています。http://git-scm.com/book/en/Distributed-Git-Distributed-Workflowsにある「統合マネージャーのワークフロー」に従います。

私たちのチーム リポジトリには、会社の他のメンバーと共有したくない独自のコードがいくつかあるため、現在のチーム リポジトリの「機能を取り除いた」バージョンを作成する必要があります。私は次のことをやろうとしています：

  1. 既存のチーム リポジトリのクローンを作成して、「統合マネージャー リポジトリ」を作成します。

  2. rmすべての独自ファイル

  3. commit実効値

  4. rebase -i --rootすべてのコミットを押しつぶして巻き戻しを防ぐ

  5. clone --bare「祝福されたレポ」を作成するための「統合マネージャーレポ」

現在、Git に比較的慣れていないため、このアプローチについていくつかの点が不確かです。

  1. 「祝福されたレポ」からチームのレポにまだプルできますか?

  2. #1 を実行できると仮定すると、rms がプルされ、すべての専有ファイルが削除されると思います。私たちのチーム リポジトリのより高度な状態を、祝福されたリポジトリ状態の子状態として表示するには、Git が必要です。これはリベースでできることですか？

  3. プラットフォームでの作業を続けるにつれて、「公開」機能と独自機能の混合物をチーム リポジトリにコミットします。「パブリック」機能のみをプッシュする最良の方法は何ですか? コミットの順序をrebase変更して、すべての「パブリック」機能のコミットがコミット履歴の先頭に来るようにしてから、最新の「パブリック」機能コミットの SHA までのみ git push できますか?

事前に助けてくれてありがとう...私は、このような大きな変更を加える前に、経験豊富な Git ユーザーによってこれを実行したかったのです。

更新 申し訳ありませんが、明確ではありませんでした...ステップ2、3、および4はすべて、「統合マネージャーリポジトリ」に適用されることを意図していました。いずれにせよ、私はさらに読んで、「パブリック」な変更を行うたびrebaseに、チームの共有リポジトリにとっては良い考えではないと判断しました.rebase

ステップ2、3、4の代わりに私がやったのrmは、「統合マネージャーリポジトリ」の.gitフォルダーで、.gitで最初からやり直しましたgit init。次に、この新しい「統合マネージャー リポジトリ」から取得し、-s oursチームのバージョンがスーパーセットであるため、フラグを使用してチームのリポジトリとマージしました。これで、チーム リポジトリとパブリック リポジトリに共通のコミットができました。チーム リポジトリに「パブリック」ブランチを作成し、この共通コミットを参照しました。今後は、パブリックに変更を加えるたびに、この「パブリック」ブランチにチェリーピックしてから、パブリック ブランチを「統合マネージャー リポジトリ」にプルする必要があります。

4

1 に答える 1

0

pull祝福されたレポからチームのレポに変更することはできませんが( rebased であるため)、変更できる場合がありcherry-pickます。もちろん、競合はおそらくあなたのルーチンの一部になるでしょう。

sをつぶしてrmしまうと、祝福されたレポでは、それらrmの s が実行されることはまったくありません。cherry-pickそのため、それらをチーム リポジトリにコミットするたびに、決して変更されないファイル (および発生する可能性のある問題) しかありません。

問題は、変更をチーム リポジトリから祝福されたリポジトリに戻すことです:)

私があなただったら (まあ、少し前に私も同じような立場にありました)、あるリポジトリから別のリポジトリに変更を移動するあらゆる種類のスクリプトを作成することを考えるでしょう。祝福されたものからチームのものに移動するときは、変更されたファイルに基づいて、おそらく見たいと思う関連の rm されたファイルについて警告を発します (存在する場合)。戻るときは、rm されたファイルへの変更を除外します。

とにかく、これは良い考えではないと思います。ワイルドになる前にトリプルチェック - ベイビーステップから始めてみませんか？

幸運を ：）

于 2013-08-13T01:17:35.657 に答える