2

私は別の組織のリポジトリのフォークを持っています。私はレポの最新のタグにいますが、これはヘッドではありません。そのタグから、上流にプッシュされることのないブランチを作成しました。そのため、私はブランチを非公開と考えています。

私は自分のプライベート ブランチにコミットし、そのコードを本番環境で使用しています。アップストリーム リポジトリに新しいタグが作成されたときに、その変更をプルできるようにしたいと考えています。

ただし、コミットを常に最後のタグの上にきちんとスタックしておきたいと思います。私のコミットは履歴のはるか昔にさかのぼってしまい、リポジトリで特定のツールを使用するときに簡単に作業できるように、それらを一番上に表示したいので、マージしたくありません。

つまり、アップストリームの変更をリポジトリに持ち込んだときに任意のポイントに移植できる「フローティング」ブランチが必要です。

[編集] ただし、履歴を書き換える操作であるため、リベースを使用できるとは思いません。ご覧のとおり、私は開発用と本番用の 2 つのマシンでリポジトリを使用しています。開発マシンでコミットを行い、github にプッシュしてから、本番環境にプルします。これらはすべて、私が最初にフォークしたアップストリーム リポジトリの変更とは何の関係もありません。

移植、チェリーピッキング、またはその他のツールが適しているかどうかは完全にはわかりません。ただし、どのツールであっても、歴史を書き換えるべきではないと私は考えています。私の読書から、プッシュ時にレポ履歴を書き換えることはできないことがわかります。したがって、履歴を書き換えずにブランチを移植するコマンドを使用する必要があるかどうかはわかりません。

Mercurial を使用していた場合、バージョン管理された mq のようなものを検討するかもしれません。git の類似のソリューションがあるかどうか、または git により適した別のツールがあるかどうかはわかりません。

[編集]

ここで得た回答を評価した後、最終的にチェリー ピッキングが正しい答えであると判断しました。すべての場合において、リベースは履歴を削除します。これは共有リポジトリであるため、少なくとも私が読んだすべてのソースによると、履歴の削除は受け入れられません。

ただし、チェリーピッキングは、コミットを元の場所から削除せずに作業ツリーにコピーします。そのため、最新のタグの上に変更のコピーを植えて、きれいな山にまとめることができます。

記録のために、hg を使用して git リポジトリのクローンを作成できる hg-git 拡張機能を使用して、Mercurial でもこれを実行しようとしました。これにはプラスとマイナスがありました。一番のマイナスは、使い終わったら押せなくなったことです。hg-git はその時点まで問題なく動作し、その後、hg 1.9 ではプッシュしないことが通知されます。控えめに言っても、偽物です。もう 1 つの欠点は、大量の変更セットの複製とプルが非常に遅いことです。ただし、mq と TortoiseHg のマージ競合解決ツールは、git cherry-pick と Smartgit のマージ競合解決よりも大幅に改善されています。hg-git が機能していればよかったのに。

最終的に、「フローティング」という表現は、変更ブランチを移動するのではなく、コピーすることになるため、私の変更ブランチの適切な説明ではなかったと思います。おそらく説明が不十分で申し訳ありませんが、オプションが何であるかを正確に把握していました。助けてくれてありがとう。

4

2 に答える 2

3 
git fetch
git rebase --onto latesttag previoustag yourbranch

競合は対処する必要があり、あるタグから次のタグに変更された可能性のあるファイルで何をしているかに完全に依存します。特に、変更したコードの一部が誰かによって削除された場合は、これに対処し、変更したコードを別の場所に適用できるようにする必要があります。これには特効薬はありません。競合を解決し、すべてが機能したら、

git add -A
git rebase --continue

すすぎを繰り返します。

追加するために、展開できるようにするためにこれを行っている場合、「フローティングブランチ」はこれに対処するための最良の方法ではない可能性があります. 次の代替案を検討してください。

  1. ファイルを操作するスクリプトをデプロイして、デプロイが確実に機能するようにします。
  2. 作業ディレクトリに入力するときにファイルを変更するスマッジ/クリーン スクリプト。( https://git-scm.com/book/en/v2/Customizing-Git-Git-Attributes#_keyword_expansion )

あなたのフローティングブランチは、あなた自身の環境のためだけにあるように見えるので、プロジェクトの一部であってはなりません.

于 2011-12-28T20:51:27.160 に答える
0

ここの仕事について説明しgit rebase --ontoます。

シナリオ：

  • git fetchリモートから;
  • セキュリティにより、新しいコピーを作成します: git branch newbranch currentbranch;
  • あなたが現在基づいている古いタグはoldtagであり、新しいタグはnewtagです。
  • 「移植」: git rebase --onto newtag oldtag newbranch;
  • 必要に応じて競合を解決します。
  • git branch -D currentbranch;
  • git branch -m newbranch currentbranch.

ただし、履歴の書き換えに関しては、元のリポジトリではなく、ブランチの書き込みアクセス権がありませんね。

于 2011-12-28T20:40:58.353 に答える