後で作成されるブランチに基づいたGit

StackOverflow https://stackoverflow.com/questions/1213185

  •  06-07-2019
  •  | 
  •  

質問

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

1つの複雑な点は、仮想マシンで実際に作業していたことです。多くのコミットでは、user.nameおよびuser.email構成エントリを設定していないことに気づかなかったため、コミットはvmのローカルユーザーからのものです。ちょっと変です。すべての変更をdiffファイルに収集し、作成された新しいブランチの上にそれらを適用する方が良いでしょうか？

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

最後の質問の1つは、 git svn を介してSVNリポジトリをインポートする場合（チェックしたばかりで現在動作しているようですが）、authorsファイルを追加しない場合、後で作成者ファイルを使用して、適切にインポートされたブランチに変更をリベースできますか？

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

SVN：

\ dir \ codez

git：

\ codez

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

役に立ちましたか？

解決

  

海外にいて、インターネット接続がおかしく、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ブランチをまだ公開していないためです。
詳細な回答：マスターに結果をマージする前に、まずブランチにリベースする必要があります。 この回答をご覧ください。
これは、ブランチをマスターにマージ（または履歴を保持する場合はリベース）する前に your ブランチの競合を解決できるため、推奨されるワークフローです。
実際には、特別な＆quot; merge＆quot;を作成することが下に表示されます。ブランチは実際にはより良いアイデアです。

  

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ヘッドではない古いバージョンのコードがそもそもあったので、その上にいくつかのものがありませんでした。続行する最善の方法は何ですか？

このインスタンスの基本的なワークフローは、新しい「マージ」を作成することです。リベースの作業を分離する（およびすべての競合を解決する）ために、現在作業中のブランチからブランチします
デルタが重要なこの種のマージでは、含めるために必要なすべての変更から作業ブランチをクリーンに保つ必要があります。

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

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

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

他のヒント

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

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

古くなった開始場所（「古いリビジョン... SVNヘッドでさえなかった」）に対処する最良の方法は、おそらく次のようになるでしょう。

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

私にとっては幸いですが、あなたにとってはそれほど重要ではないので、git-svnを使用する必要はないので、著者ファイルの質問に明確に答えることはできません。しかし、私が正しく理解していれば、authors-fileはSVN著者をgit著者に翻訳します。著者がgitコミットで変更すると、ハッシュが変更されます。したがって、この変換テーブルを台無しにせず、最初から正しく変換することが重要です。

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

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

$ git symbolic-ref HEAD refs/heads/new_branch

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

これはあなたの状況に役立つかもしれませんし、そうでないかもしれません。 YMMV。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top