1

私はソース管理にSubversionを使用し、Gitと組み合わせてherokuにデプロイ（プッシュ）していました。私のパターンは次のとおりです。リモートSubversionリポジトリで最新のマスターからローカル作業コピーを更新します。次に、gitcommitとgitpush herokuを実行します（Gitは.svnのものを無視するように設定されています）。この作業コピーは、herokuにプッシュするためにのみ使用しました。ライブ開発を実行し、追跡のためにリモートSubversionリポジトリにコミットするための別のSubversionフォルダーがありました。

完全にgitに切り替えました。Subversionから新しいリモートgitリポジトリに完全にインポートしました。私はgitrepo（origin）のローカル作業コピーの作業に成功し、自分に合ったときに変更をプッシュしました（他の開発者とも協力していますが、基本的に操作を実行します）。

私の質問：

ここで、以前にherokuにプッシュするために使用していた他のgit作業コピー（.svn /のものも含まれています）に戻りたいと思います。新しいgitリポジトリを.git/configの[origin]エントリとして追加することを考えています。新しいgitリモートから最新の変更をプルし、herokuにプッシュしますが、それがおかしくなりそうかと思います。 。

マージして混乱してしまいますね。そして、プルが機能したとしても、herokuリモートはいくつかの新しいgitリポジトリから発生したプッシュについて混乱しますか？

その作業コピー（subversionからherokuにプッシュするために使用）を複製（削除）し、新しいgitリポジトリの新しいクローンを作成してから、herokuを.git/configに追加することができます。ただし、以前は別の作業コピーからプッシュしていたため、herokuにプッシュすると混乱が生じるのではないかと心配しています。

どんなアドバイスも素晴らしいでしょう！

前もって感謝します！

4

1 に答える 1

1

私の理解が正しければ、作業コピーとして元の SVN リポジトリに戻し、古い SVN 履歴を保持したいですか?

利用可能なオプションがいくつかあります。

  1. 最新の変更を新しい Git リポジトリから Heroku にプッシュしてから、古いリポジトリに切り替えて Heroku からプルします。これにより、古いリポジトリが最新の状態になります。

  2. 古いリポジトリの構成ファイルの URL を一時的に変更して、新しいリポジトリのローカル パスを指すようにします。そこから最近の変更を取得し、完了したら Heroku URL に戻します。これにより、古いリポジトリも最新の状態になります。

最初のオプションが最も適切で、2 番目のオプションは長い道のりです。どちらの方法でも、すべての履歴を含む最新のローカル リポジトリと同じ結果が得られます。余剰の新しいリポジトリは、いずれの場合も処分できます。

編集: Heroku がコミットの発信元を気にするかどうかについての懸念に対処するために、簡単に言えば、Heroku のリポジトリは、認証されたユーザーからのコミットを受け入れる別の git リポジトリではありません。

認証情報が正しい限り、元のリポジトリは問題ではありません。これは DVCS の優れた点です。制御または破損可能なリポジトリが 1 つもありません。別のマシンで Heroku からクローンを作成し、そこから作業を続行することが完全に可能です。資格情報が同じである限り、履歴にはプッシュしたすべてのコミットが表示されますが、どこからのものかは関係ありません。

単純にクリーンなリポジトリを使用して作業したい場合は、新しいリポジトリが最適です。古いものは悪影響なく削除できます。

これを証明するには、新しいリポジトリと古いリポジトリの両方でコミットの SHA-1 ハッシュを確認すると、それらが同一であることがわかります。ハッシュはすべてのコミットに対して一意であり、コードの整合性を常にチェックするために使用できます。特定のハッシュに対して複数の変更が行われることはありません。

  • 補足として、リポジトリは完全に自己完結型であり、ストレージスペースで自由に移動したり、USB サムドライブなどの外部ストレージで使用したりできるという点で移植性があります。
于 2009-09-27T05:04:54.753 に答える