問題タブ [git-rebase]

コミットが git rebase -i でどのように押しつぶされるのかよくわかりません。私が疑問に思ったことが1つあります。

私の rebase -i がこのリストを生成する場合:

コミット A と B または B と C をスカッシュする必要がありますか? 問題は、この場合、C..A を C にリベースするのではなく、D..A を D にリベースする (D はこの前の最後のコミット) という git です。D はまったく表示されないのに、なぜそのように表示されるのでしょうか。

別の質問によると、それは+git pullのようなものです。git fetchgit merge

git pullしかし、とgit fetch+の違いは何git rebaseですか?

線形ブランチを押しつぶしたり修正したりしようとしたときに、手動でマージする必要があるのはどうしてですか？リポジトリはSubversionから変換されました。すべての競合は、「自動チェリーピックに失敗しました」または「空のコミットメッセージのためにコミットを中止します」のいずれかです。後者は理解できましたが、--fixup-emptyまたは何かが役立つでしょう。

典型的な出力：

master から "feature" ブランチを作成し、長い間作業しました。次に、最新のマスター ブランチのコミットを取得し、その上に「機能」ブランチのコミットをリベースしました。次に、「機能」をマスターにマージしました。しかし、マージのことを忘れて、「feature」ブランチにコミットし続けました。これらのコミットを新しいブランチに入れたいので、マスターへの最後のマージ以降の「feature」ブランチでのコミットに基づいて、別のブランチ「feature_2」を作成したいと思います。助言がありますか？

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 リポジトリにちょっとした混乱を引き起こすことができました。次の手順を使用して、壊れたコミットを修正しようとしていました。「git commit --amend」を実行する前 (および git rebase --interactive の後) に、自分の変更が正しくないと判断したため、「git reset HEAD --hard」を実行しました。良い考えではありません、私はあなたに言います。

現在、インタラクティブなリベースは「スタック」しているようです。Git は現在のブランチを (|REBASE-m) として表示します。私のリポジトリ内のすべてのコマンド（cd ..、ls、git rebase ...）は、次のエラーを出します：

cat: .git/rebase-merge/head-name: そのようなファイルやディレクトリはありません

git rebase --abort は次のようになります。

git rebase --continue の結果は次のとおりです。

何か案は？よく考えたリベース操作を開始する前の状態に状況をリセットしたいと思います。

git log --oneline が状況を示す方法は次のとおりです。

そして、これは問題ありません。

私は msysgit v1.7.0.2 を使用しています。

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

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

git rebase オリジン/B

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

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

git rebaseファイルがリポジトリに追加され、次にリポジトリから削除され、作業ディレクトリに追加される (ただし、リポジトリには追加されない) 特定のケースでは、正しく動作しないように見えます。

私の問題のより具体的な説明は次のとおりです。

• ブランチが作成され、トランクから切り替えられた場合、

• ファイル X が追加され、ブランチにコミットされます。

• その後、X が削除され、ブランチでコミットされます。

• X は再び作業ディレクトリに作成されますが、追加もコミットもされません。

• そして幹の枝が進み、

• それから

• 高度なトランクをベースとして使用して実行されたリベースは、X の上書きを拒否するため失敗します。

• また、作業ディレクトリ X が削除または移動されても、リベースを続行することはできません。

コマンドラインで私の問題を再現するスクリプトは次のとおりです。

git rebase --abort、 remove bar.txt、そしてgit rebase masterもう一度使用して、リベースを中止できることはわかっています。しかし、最初に中止せずにリベースを続行するにはどうすればよいでしょうか?

多くのオープンソース プロジェクト (例: django ) には GIT ミラーがあり、これらはプライベートまたはパブリック開発用にフォークされています。GIT ミラーは、最新の状態に保たれていますgit svn rebase。しかし、Pro Git Bookには次の明確な推奨事項が含まれています。

ああ、しかし、リベースの至福には欠点がないわけではありません。これは次の 1 行に要約できます。

公開リポジトリにプッシュしたコミットをリベースしないでください。

そのガイドラインに従えば、問題ありません。そうしないと、人々はあなたを憎み、友人や家族から軽蔑されるでしょう.

何かをリベースすると、既存のコミットが破棄され、似ているが異なる新しいコミットが作成されます。コミットをどこかにプッシュし、他の人がそれらをプルしてベース作業を行った後、それらのコミットを git rebase で書き直して再度プッシュアップすると、共同作業者は作業を再マージする必要があり、あなたがしようとすると物事が混乱します。彼らの仕事をあなたの仕事に戻します。

Django のようなオープンソース ミラーは、公開リポジトリにリベースしないという上記の太字の規則を破っていますか? そうでない場合、なぜですか？もしそうなら、「通常の」リベースされていない Git プロジェクトで実行できるこれらのミラーを使用して実行できないことは何ですか? これが明白な質問である場合はお詫びします。私はGitの初心者です。

次の git ワークフローをセットアップできるようにしたいのですが、rebase、remote など、どのコマンドを使用すればよいかわかりません。

1. Git リポジトリへの読み取り専用アクセスしか持たないオープン ソース プロジェクトのクローンを作成する
2. プロジェクトに変更を加えて、それらの変更を私のプライベート github リポジトリに保存します - それを「開発」と呼びましょう
3. 開発の変更が安定したら、「ステージング」に移行します
4. 「ステージング」がテストされたら、変更を「本番」に移動します
5. リモート オープン ソース プロジェクトを同期し、常に変化しているため、たとえば毎週同期してから、プロセス全体をもう一度開始します。

ありがとう