問題タブ [rebase]

私はブランチから git rebase を行っています。ここで 3 つの変更を取得しましたが、10 のようにリベースしました。本当に git pull を使用したかったのです。私はまだ git を学んでいないと思います。変更が公開されました...

私はむしろ git pull を実行したかったので、上位ブランチの 12 ほどのコミットをリベースするのではなく、3 つのチェックインのみが上位ブランチに追加されます。

これをきれいにする方法はありますか？または、先に進みます。おそらく正当な理由で、Githubはコミットを取り消すことを許可しません。

.NET ベースのクライアント側アプリを高速化したいだけで、コードを NGEN 化することを検討しています。

Jeffery Richterは、 ngening コードに関する次の警告を書きました。

•ロード時のパフォーマンスの低下 (リベース)。Windows は、NGend ファイルをロードするときに、ファイルが優先ベース アドレスにロードされているかどうかを確認します。ファイルが優先ベース アドレスにロードできない場合、Windows はファイルを再配置し、すべてのメモリ アドレス参照を修正します。Windows はファイル全体をメモリにロードし、ファイル内のさまざまなバイトを変更する必要があるため、これには非常に時間がかかります。リベースの詳細については、私の著書『Programming Applications for Microsoft Windows, 4th Edition』(Microsoft Press) を参照してください。

このトピックについてあまり知らないので、プロジェクト内の設定を変更する前に何を知っておくべきですか? また、どの設定を変更する必要がありますか?

最近、hg リポジトリを git にクローンしたので、github に投稿できます。多くの電子メール アドレスが間違っているため、誰かがこのプロジェクトをフォークする前に、git rebase を使用してそれらを変更したいと考えています。それらを変更した場合、完全にリベースされた新しいリポジトリを github にプッシュするにはどうすればよいですか? リベースしてからでき git pushますか？最初にプロジェクトを削除する必要がありますか?

現在の状況：

その履歴（A1からB3）、特にをクリーンアップしたいと思います。まだどこにもプッシュしていないので、B*だけのパッチを作りたいからです。

私が欲しいのは：

私はおそらくこれをまったくプッシュしません（または、合計されたB *のみをプッシュする場合は、A *コミットを完全に削除する必要があります）。これにさらに取り組んでいる間、追加のそのようなコミットを取得する可能性があります。

そして、それを上記のように書き直したいと思います。

私はこれを行う方法を知りたいだけではありません（私はややハッキーな方法でsthを取得できるため）、私は特にそうです。これを行うための正しい/最良/最もクリーン/最も簡単な方法をここで求めます。

私がしていること、特に。は：私は公式のxorg-xserver-1.7ブランチに取り組んでおり、パッチ（B *）を準備したいと思っています。簡単なテストのために、自己コンパイルしたxserverをシステムのものに置き換えたいので、Debian / Ubuntuパッチ（A *）をたくさん適用しました。ただし、そのパッチをどこかに投稿する場合は、それらを除外したいと思います。

これは、リベースのアイデアを説明するA VisualGitReferenceからのキャプチャです。

http://a.imageshack.us/img339/4264/screenshot20100903at102.png

私の理解は次のとおりです。

• gitは変更を追跡しているため、169a6と2c33aはコミットa47c3からの変更を（追跡し）ます。
• リベースとは、da985に変更を適用することを意味します。その結果、f7e63にはb325cからe57cfへのすべての変更があります（追跡します）。

質問。

• 私の理解は正しいですか？
• もしそうなら、169a6と2c33aの変更がコミットda985で（安全に）適用できることをどのように確認できますか？
• そうでない場合は、リベースが何をするのか説明できますか？

feature-xと呼ばれる長命のブランチ (ずっと後にリリースされる) での過去のコミット以降に発生したバグの原因を見つけようとしています。

バグはあるけど。特に master の機能は feature-x で頻繁に使用されていますが、Master 自体ではあまり使用されていないため、これまでのコミットのいずれかで導入された可能性があるスクリプトからは予期しない動作を見つけました。

この動作をテストするには、スクリプトdependent.pl を実行する必要があります。しかし、bisect がコードの途中までジャンプすると、私のスクリプトはマスターに存在しないため、テストできません。

これは bisect があなたを頭のない状態に引きずり込むためだと思いますが、この場合、私は本当にこの他の履歴/変更セットのコンテキストになりたいと思っており、エーテルに浮かんでいません.

誰かがあなたのやり方が間違っているブザーを鳴らす前に、私たちのチームはこのような状況でブランチをマージすることを好みます。

サンプル リポジトリを作成して、これをデモします。

これで、次のようなレポが得られます。

git bisect start feature-x dev-1.0したがって、dependent.pl でコードを壊した原因を見つけることができることを期待してコマンドを実行すると、feature-x からの変更履歴なしで commit 'sub f { return 2 }' になります (つまり、 を実行するlsと、私が見るのは main.pl だけで、dependent.pl がありません)。

これは私をテストできない状態にします。現在のコミットが私の作業を壊したかどうかはわかりませんし、マスターでのコミットがそれを壊したとは言えません。したがって、このコミットが良いとも悪いとも言えません。

現在のブランチを壊した原因をテストするにはどうすればよいですか?

git push origin B を作成できません。このような状況があります

Git は私にやるべきことを提案します

git rebase オリジン/B

これはブランチ C にとって危険ですか?

以前に C を一時的な場所にリベースする必要がありますか?

私たちの仕事のやり方に合った Mercurial ワークフローを見つけるのに苦労しています。

私は現在、機能ごとのクローンを支持していますが、これは Subversion からの考え方のかなりの変化です。また、環境のセットアップにかかる現在の費用にも問題があります。

hg pull --rebase を使用すると、Subversion に似たワークフローが得られるように見えますが、いろいろ読んでみると、使用には慎重です。

私は概念を理解していると思いますし、歴史を書き直すことは理想的ではないことがわかりますが、私が個人的に容認できないと考えるシナリオを思い付くことができないようです.

hg pull --rebase が理論的または経験的に作成できる「最悪の」シナリオは何かを知りたいです。歴史を「書き換えるべき」かどうかについての意見ではなく、具体的な例が欲しいです。私は人々が意見を持っていることに反対しているわけではありませんが、インターネット上では多くの意見が表明されているように見えますが、それらを裏付ける例はあまりありません ;)

Gitには、履歴を変更するための一連の手順があります。
（、、、、、など）rebase_ filter-branch_commit --ammendguiltstacked git

ただし、最後のいくつかのコミットを、コミットメタデータを含む一連のパッチを含むファイルに変換する手順があれば、それが望ましい場合があります。このファイルは、自由に編集して、リベースされた履歴に戻すことができます（パッチがまだ残っていると仮定します）。適用）。

誰かがこれを行う方法がありますか？

私は3つのことを設定しようとしています：

1. パブリック SVN リポジトリのパブリック GIT ミラー
2. 複数の貢献者がパッチをステージングできる、そのレポの公開フォーク
3. #2 からのパブリック リポジトリのプライベート フォーク

#1 のやり方は知っていますが、#2 と #3 についてのアドバイスを探しています: 構成方法、同期を維持する方法、避けるべきことなど。

詳細は次のとおりです。

私が使用している SVN ベースのオープンソース Web アプリケーションのパッチ送信メカニズムは遅くて非効率的です。問題追跡システムに送信されたバグにパッチが添付され、数週間または数か月後にそれらのパッチがトランクに入れられます。

別の問題は、私の会社だけが必要とする追加機能を備えたプロジェクトのプライベート フォークを維持する必要があることです。しかし、フォークがトランクからの最新の公式コミットを最新の状態に保つ簡単な方法が必要です。

これらの問題の両方に対する GitHub ベースのソリューションを見つけたいと思います。締めくくりたいのは以下の3点です。

• 「ミラー」 - SVN の GitHub ミラー。私または別のパッチ提供者が実行する自動化されたプロセス (この記事のような) を介して、最新の SVN の変更と自動的に同期されます。これにより、SVN をいじることなく、私や他の誰かがプロジェクトのパブリックまたはプライベート フォークを簡単に作成できるようになります。
• 「contrib」 - 私自身と信頼できる数人のパッチ提出者のために、「ミラー」のパブリック フォーク (またはブランチ?) をセットアップして、最終的に SVN に表示されるようにしたいパッチをコミットできるようにしたいと考えています。これにより、コア コミッターがパッチを SVN に戻すのがより簡単かつ効率的になる可能性もあります。
• "ourfork" - 最後に、私たちの会社は、複数の開発者が私たちの会社の実装にのみ適用されるプライベート機能を追加できる "contrib" のプライベート フォークをセットアップしたくないと考えています。

具体的な質問:

• アプローチは理にかなっていますか？代わりに使用すべきより簡単なソリューションはありますか?
• 「contrib」が「mirror」と同期していることを確認する方法は? 競合しない限り、新しいコミットを自動的に適用する GitHub マジックはありますか? いいえ、contrib が親と同期していることを確認するための適切なワークフローは何ですか?
• 「ourfork」は論理的には「mirror」の孫になります。「ミラー」と「contrib」の両方からの変更で最新の状態に保つための正しいワークフローは何ですか? 「contrib」を唯一のリモートとして設定する必要がありますか? または、両方をリモートとして設定します。もしそうなら、マージの正しいプロセスは何ですか?

同様の質問に対する@rqの回答を読んだところ、上記の質問のほとんどに回答していると思いますが、私はGitの初心者であり、彼の回答が私のケースに当てはまるかどうかわかりません.