2

現在svnで追跡されているWebサイトプロジェクトに取り組んでいますが、他の誰かが新しいサーバーなどをセットアップする時間があれば、gitに移動します。長い話になりますが、それまでの間、私が持っていたコードから独自の git リポジトリを作成し、かなりの作業を行いました。私は海外にいて、インターネット接続が奇妙でHTTPのプロキシが必要で、git svnが通過できないように見えるため、git svn cloneを使用しませんでした。いずれにせよ、私は自分の git リポジトリで開発を行ってきましたが、最終的にプロジェクトが実際に適切にインポートされたら、自分の作業を git-svn のクローンにリベースする必要があります。git rebaseこれは適切に機能しますか？

問題の 1 つは、私が実際に仮想マシンで作業していて、多くのコミットで、user.name と user.email の構成エントリを設定していなかったことを認識していなかったため、コミットが vm のローカル ユーザーからのものであったことです。奇妙なの。すべての変更を diff ファイルにまとめて、作成された新しいブランチの上に適用する方がよいでしょうか?

もう 1 つの問題は、以前の SVN の使用が中途半端だったことです。そのため、実稼働サーバーには、私が持っていなかったコミットされていない変更が実際にありました。実際には、SVN ヘッドでさえないコードの古いリビジョンを最初に持っていたので、その上にいくつかのものが欠けていました。続行する最良の方法は何ですか?

最後の質問の 1 つは、SVN リポジトリを経由してインポートした場合git svn(チェックしたところ、現在は機能しているようです)、作成者ファイルを追加しない場合、後で適切にインポートされたブランチに変更をリベースできるかどうかです。著者ファイルで？

ああ、新しい合併症。私は を使用して SVN リポジトリを自分でインポートしましたgit svn。これは、この遅い接続で 2 日間の大半を費やした大変なプロセスでした。しかし、最終的にクローンを作成した後、SVN リポジトリではコードがすべてサブディレクトリにあることに気付きましたが、私の git リポジトリではリポジトリのルートがディレクトリのルートでもありました。これが少し混乱している場合、基本的にはこのようなものです

SVN:

\dir\codez

ギット：

\codez

2 つのリポジトリを結合するにはどうすればよいですか? リベースを引き続き使用できることを願っていますが、これは非常に奇妙な状況のようです。サブモジュールに似ているように聞こえますが、それは私が必要としているものではないと思います。

4

3 に答える 3

5

私は海外にいて、インターネット接続が変で、HTTP のプロキシが必要なので、git svn clone を使用しませんでした。

設定すれば動作するはずです

http_proxy=http://username:passwword@pprroxyHost:proxyPort

またはあなたが試すことができます

http_proxyUser=username
http_proxyPassword=password
http_proxyHost=aProxyHost
http_proxyPort=aProxyPort

これに対して git rebase は適切に機能しますか?

一般的な回答: はい、まだ Git ブランチを公開していないためです。
詳細な回答: master で結果をマージする前に、最初にブランチにリベースする必要があります。この回答を参照してください。これは、ブランチを master にマージ (または履歴を保持したい場合はリベース) する前に、
ブランチ内の 競合を解決できるため、推奨されるワークフローです。 実際には、特別な「マージ」ブランチを作成する方が実際にはより良いアイデアであることが以下に示されています。

user.name および user.email 構成エントリを設定していないことに気づいていませんでした

まだ公開していないので、を使用しfilter-branchてコミットを変更し、ユーザー名と電子メールを変更できます

ちょっとしたshスクリプトが役に立ちます

#!/bin/sh

git filter-branch --env-filter '

n=$GIT_AUTHOR_NAME
m=$GIT_AUTHOR_EMAIL

case ${GIT_AUTHOR_NAME} in
        aSystemUserName) n="TheActual Name" ; m="TheActual@mailAddress" ;;
esac

export GIT_AUTHOR_NAME="$n"
export GIT_AUTHOR_EMAIL="$m"
export GIT_COMMITTER_NAME="$n"
export GIT_COMMITTER_EMAIL="$m"
'

このスクリプトをレポから呼び出すと、完了です。

そもそもSVNの頭でさえない古いリビジョンのコードを持っていたので、その上にいくつかのものが欠けていました。続行する最良の方法は何ですか?

この場合の基本的なワークフローは、現在の作業ブランチから新しい「マージ」ブランチを作成して、リベース作業を分離する (そしてすべての競合を解決する)
ことです。デルタが重要なこの種のマージでは、作業を続けなければなりません。以下を含めるために必要なすべての変更からブランチ clean を実行します。

  • SVN からのコード
  • SVN リポジトリから直接取得しなかったコード。

後で、作成者ファイルを使用して適切にインポートされたブランチに変更をリベースできますか?

確かではありませんが、そう思います。そうでない場合は、まだ何も公開していない限り、filter-branch名前変更スクリプトを再度使用することをお勧めします...

于 2009-07-31T15:48:52.603 に答える
1

git-rebase履歴のどこかに共通のコミットがあることに依存します。また、単一のリポジトリ内でも発生します。(a) 新しい git-svn インポート リポジトリが自分のものとは別であり、(b) 2 つの間に共通のコミットがないという状況に陥りそうです。おそらくパッチを介してこれを行う必要がありますが、git がこれを支援します。git-format-patchおよびのマンページを確認してくださいgit-am。1 つ目は一連のコミットから一連のパッチを生成でき、2 つ目はこの一連のパッチを取得して適用できます。すべてのコミット メッセージなどは保持されます。

これにより、user.name/email の問題を修正する機会が得られます。パッチを適用する前に、パッチのヘッダーでそれらを変更し、新しくインポートされたリポジトリで正しく設定されていることを確認してください。

時代遅れの出発点（「古いリビジョン...それはSVNの頭でさえありませんでした」）に対処する最良の方法は、おそらく次のようになります。

  • すべての変更をコミットして、SVN リポジトリを良好な状態にする
  • git-svnでインポート
  • 作業を開始した古いコミットでブランチを作成してチェックアウトする
  • パッチシリーズを適用する
  • このブランチを現在の SVN ヘッドに対応する master にマージします

私にとっては幸運ですが、あなたにとってはそうではありませんが、git-svn を使用する必要はありませんでした。ただし、私の理解が正しければ、authors-file は SVN の作成者を git の作成者に変換します。git commit で作成者が変更されると、ハッシュが変更されます。したがって、この変換テーブルをいじらず、最初から正しく設定することが重要です。

ここにはたくさんの質問がありましたので、お気軽にコメントして、見逃した場合はさらに質問してください.

于 2009-07-31T15:50:06.140 に答える
0

低レベルのツールを使用して、新しい胎児ブランチを作成できます。

$ git symbolic-ref HEAD refs/heads/new_branch

--root最新のgitでは、「gitrebase」のオプションを使用してブランチ全体をリベースできます。

これは、状況に役立つ場合とそうでない場合があります。YMMV。

于 2009-07-31T18:11:32.923 に答える