5

質問の要約：

私はこれを書いたときに多くの詳細があることに気づきました、それでここに見出しがあります：

  • 作業環境内でSVNとGitSVNを使用しているが、リモートGitリポジトリ（BitBucket）を使用して作業環境の外部から同じコードにアクセスし、変更を共有したい多くのユーザーのチームにとって、優れたワークフローは何ですか？不在時にこのコードを相互に接続し、オフィスに戻ったときに安全にSVNにリベースしますか？他の人もオフィス内でローカルにGitSVNを使い続けていますか？

これを書いていると、私が求めていることは本当に非常に複雑であり、単に不可能かもしれないことに気づきました...

詳細：

私はSVNリポジトリを使用している人々のチームと協力しています。私たちの多くはGitSVNの使用を開始し、現在Gitをローカルで使用するメリットを享受しており、気まぐれに分岐し、必要に応じてローカルマスターにマージしてから、SVNに戻っています。これはうまく機能します（ただし、純粋なGitソリューションのすべてのメリットを享受しているわけではありません）。

最近、マスターのリモートとしてプライベートBitBucket Gitリポジトリを使用し始めたので、他の場所との間でコードを簡単に転送できます。ワークフローは次のとおりです。

  • 職場では、SVNトランクからリベース=>ローカルワークマスター。
  • ローカルワークマスターからのプッシュ=>BitBucketマスター。
  • 自宅では、BitBucketマスター=>ローカルホームマスターからプルします。
  • 自宅でコーディング、分岐、マージ、gitを楽しんでください。
  • ローカルホームブランチからマージ=>ローカルホームマスター。
  • ローカルホームマスターからのプッシュ=>BitBucketマスター。
  • 職場では、BitBucketマスターからローカルワークマスターにプルします。
  • SVNトランクに対してリベースします。
  • SVNにコミットします。

さて、いくつかのステップがありますが、それは私にとってはうまくいきます。しかし、私の同僚の多くは、同じようなことを始めたいと思っています。さらに、SVNを邪魔することなくBitBucketGitリポジトリを使用できるようにしたいと考えています。

私たちが検討している種類のもののいくつかの例：

  • 私たちの1人が不在の場合、彼らは最新のコードを入手できることを望んでいます。仕事では、SVNからリベースしてから、BitBucketにプッシュして、同僚が最新のコードを利用できるようにすることができます。
  • 2人で変更を共有したい場合（一方または両方が不在であると想定）、BitBucketでこのための機能ブランチを作成し、必要に応じてプッシュおよびプルすることができます。
  • 満足したら、ローカルホームマスターにマージしてからBitBucketマスターにプッシュし、仕事に戻ったときにプルできるようにします。
  • 仕事に戻ったら、私たちの1人がMasterをBitBucketからLocal Work Masterにプルし、SVNに対してリベースして、通常どおりdcommitすることができます。

しかし、私たちの1人がこれを行ったとすると、チームの他のメンバーはどうなりますか？BitBucketマスターからプルすると、変更が適用されます。ただし、SVNからリベースすると、変更も取得されます。

彼らが両方を行うとどうなりますか？そして、これは考えられる障害の1つにすぎません。私は他の一連のステップを考えることができます。これはすべて実際の混乱に陥る可能性があります。

残念ながら、継続的インテグレーションのワークフローは、他のビジネスと同様にSVNに関連付けられています。したがって、Git全体に移行するオプションは実際にはありません。また、社外からSVNリポジトリにアクセスすることもできません。

4

2 に答える 2

3

GitリポジトリとSVNリポジトリを同時に使用したい人のために設計されたSubGitプロジェクトをご覧ください。SVNサーバーにアクセスできる場合は、実行するだけです

$ subgit install path/to/svn/repository

その後、リポジトリのGitインターフェースが作成されます。GitリポジトリへのすべてのプッシュはSVNに変換され、その逆も同様です。新しく作成されたGitリポジトリへのアクセスを設定するだけです。

SVN <-> Gitミラー用の一部のgit-svnベースのスクリプトは同様の機能を提案しますが、SubGitと比較して欠点があります。

  • 同時実行性の問題：誰かがSVNとGitに同時にプッシュすると、リポジトリーの履歴が分岐します（SubGitは同時実行性を考慮します）。
  • git-svnリポジトリは、SVNのような概念のみを許可します（たとえば、Gitサブモジュールを持つことは許可されません---「gitsvn dcommit」は、ローカルに追加されたサブモジュールを削除します）
  • git-svnはsvn：ignoreを.gitignoreに変換しません
  • git-svnは行末を正しく処理しません（つまり、svn：eol-styleを尊重しません）
  • git-svnは匿名のGitブランチを変換せず、それらのブランチでのコミットはSVNに入ることがありません
  • git-svnは常にGitマージコミットをSVNに変換するとは限りませんsvn：mergeinfoの変更は正しく行われます
  • git-svn dcommitは、Git-> SVN変換中、Gitコミットの日付を保持しません...

git-svnの利点は、Gitミラーを別のマシンに保持できることです。ただし、同時実行性の安全性でそれを実現します（同じマシン上にあることは、変換期間中、SVNリポジトリとGitリポジトリの両方を短時間ロックする条件です）。

于 2012-07-14T14:08:49.293 に答える
1

gitサーバーをsvnリポジトリと同期するのは簡単なことではありません。1つはgitを使用し、もう1つはsubversionを使用する、2つのサーバーを使用する場合は、次の問題が発生します。

  • Subversionは、gitと同じようにブランチを理解しません。ブランチ間でgitでいくつかのマージを行う場合、これはsvnにも渡すことができます。しかし、破壊の場合、すべてが1つのブランチで発生したため、情報を失うことなくその逆は不可能です。
  • dcommitすると、変更がリベースされます。これは、コミットが新しいshaを取得することを意味します。変更をSubversionからgitにマージして戻すと、gitは混乱します。

私は仕事で同じ同期を実行しようとしました（ビルドプロセスでもsvnに関連付けられていました）。いくつかの実験の結果、確実に機能することがわかったのは、誰もが使用するgitサーバーを使用し、変更を同期することです。使用するjenkinsまたは統合サーバーも最新の変更を取得できるようにSubversionに変換します。これを実現する最も簡単な方法は、git->svnという一方向にのみ同期することです。これは、誰もsvnにコミットしないことを意味します（git同期プロセスを除く）。

このソリューションが機能する場合は、その方法を文書化し、自動的に実行するためのスクリプトをいくつか作成しました。あなたはこの投稿でそれを見つけることができます。

于 2012-07-14T13:10:26.510 に答える