問題タブ [git-rebase]

gitリベースを簡単に元に戻す方法を知っている人はいますか？

頭に浮かぶ唯一の方法は、手動でそれを行うことです。

• git checkoutは、両方のブランチの親をコミットします
• 次に、そこから一時ブランチを作成します
• チェリーピックすべてのコミットを手作業で
• リベースしたブランチを手動で作成したブランチに置き換えます

私の現在の状況では、両方のブランチからのコミットを簡単に見つけることができるので、これはうまくいくでしょう（1つは私のもので、もう1つは私の同僚のものでした）。

しかし、私のアプローチは、最適ではなく、エラーが発生しやすいと思います（たとえば、自分のブランチを2つ使用してリベースしたとしましょう）。

何か案は？

明確化：私は、コミットの束が再生されたリベースについて話している。1つだけではありません。

A、B、Cの 3 つのコミットを含む履歴があるとします。

2 つのコミットAとBを 1 つのコミットABに結合したいと思います。

私は試した

これにより、次の内容でエディターが開きます。

これを次のように変更します

次に、Git 1.6.0.4 は次のように述べています。

方法はありますか、それとも不可能ですか？

私は、他の開発者とのプロジェクトで数か月間 Git を使用しています。私はSVNで数年の経験があるので、関係に多くの荷物を持ってきたと思います。

Git は分岐とマージに優れていると聞いたことがありますが、これまでのところ、そのようには見えません。確かに、分岐は非常に単純ですが、マージしようとすると、すべてがうまくいきません。今、私はSVNからそれに慣れていますが、ある標準以下のバージョン管理システムを別のシステムと交換しただけのようです。

私のパートナーは、私の問題は意地悪にマージしたいという私の欲求から生じていること、そして多くの状況でマージの代わりにリベースを使用する必要があることを教えてくれました。たとえば、彼が作成したワークフローは次のとおりです。

基本的に、機能ブランチを作成し、常にマスターからブランチにリベースし、ブランチからマスターにマージします。注意すべき重要なことは、ブランチは常にローカルのままであるということです。

これが私が始めたワークフローです

本質的な違いが 2 つあります (私が思うに): 私はリベースの代わりに常にマージを使用し、フィーチャー ブランチ (およびフィーチャー ブランチのコミット) をリモート リポジトリにプッシュします。

リモート ブランチを使用する理由は、作業中に作業をバックアップしたいからです。リポジトリは自動的にバックアップされ、問題が発生した場合に復元できます。私のラップトップはそうではないか、それほど完全ではありません。したがって、他の場所にミラーリングされていないコードをラップトップに置くのは嫌いです。

リベースの代わりにマージする理由は、マージが標準のように見え、リベースが高度な機能のように見えるからです。私の直感では、私がやろうとしていることは高度なセットアップではないので、リベースは不要なはずです。私は Git に関する新しいプラグマティック プログラミングの本も熟読しましたが、それらはマージを広範囲にカバーし、リベースについてはほとんど言及していません。

とにかく、私は最近のブランチで自分のワークフローに従っていましたが、それを master にマージしようとすると、すべてがうまくいきませんでした。重要ではないはずのものとの衝突がたくさんありました。対立は私には意味がありませんでした。すべてを整理するのに 1 日を要し、最終的にリモート マスターへの強制的なプッシュが行われました。

このようなものの「正しい」ワークフローは何ですか? Git は分岐とマージを非常に簡単にするはずですが、私はそれを見ていません。

2011 年 4 月 15 日更新

これは非常によくある質問のようです。最初に質問してから 2 年間の経験を更新したいと思います。

少なくとも私たちの場合、元のワークフローは正しいことがわかりました。言い換えれば、これが私たちがしていることであり、機能します。

実際、生のマージではなくスカッシュ マージを行う傾向があるため、ワークフローは少し異なります。(注: これは議論の余地があります。以下を参照してください。 ) これにより、機能ブランチ全体を master 上の単一のコミットに変えることができます。次に、機能ブランチを削除します。これにより、ブランチ上でコミットが少し乱雑であっても、マスター上でコミットを論理的に構造化することができます。だから、これは私たちがすることです：

スカッシュ マージの論争- 何人かのコメンターが指摘しているように、スカッシュ マージはフィーチャー ブランチのすべての履歴を破棄します。名前が示すように、すべてのコミットを 1 つにまとめます。小さな機能の場合、これは 1 つのパッケージに凝縮されるので理にかなっています。より大きな機能の場合、特に個々のコミットがすでにアトミックである場合は、おそらく良い考えではありません。それは本当に個人的な好みに帰着します。

Github と Bitbucket (その他?) のプル リクエスト- マージ/リベースがプル リクエストにどのように関連するのか疑問に思っている場合は、マスターにマージする準備が整うまで、上記のすべての手順に従うことをお勧めします。手動で git とマージする代わりに、PR を受け入れるだけです。これはスカッシュ マージを行わないことに注意してください (少なくともデフォルトではそうではありません) が、非スカッシュ、非早送りがプル リクエスト コミュニティで受け入れられているマージ規則です (私の知る限り)。具体的には、次のように機能します。

私は Git が大好きになり、SVN には戻りたくありません。苦労している場合は、そのまま続けてください。最終的には、トンネルの終わりに光が見えます.

を使用git rebase --interactive <commit>すると、任意の数のコミットを 1 つのコミットにまとめることができます。

コミットを最初のコミットに押しつぶしたくない場合を除き、これで問題ありません。それは不可能に思えます。

それを達成する方法はありますか？

適度に関連する:

関連する質問で、私は最初のコミットに対して押しつぶす必要がある別のアプローチを考え出すことができました。

興味がある場合: git: 最初にコミットを挿入し、他のすべてをシフトする方法は?

以前、git リポジトリで最初の 2 つのコミットをつぶす方法について質問したことがあります。

解決策はかなり興味深いものであり、git の他のいくつかのものほど気が遠くなるようなものではありませんが、プロジェクトの開発中に手順を何度も繰り返す必要がある場合は、まだ少し厄介です。

したがって、私は一度だけ苦労して、標準のインタラクティブなリベースを永遠に使用できるようにしたいと考えています。

したがって、私がやりたいことは、最初のコミットのみを目的として存在する空の初期コミットを作成することです。コードも何もありません。リベースのベースになるようにスペースを占有するだけです。

私の質問は、既存のリポジトリがある場合、最初のコミットの前に新しい空のコミットを挿入し、他のすべての人を前に移動するにはどうすればよいですか?

NASMソースファイルからいくつかのPerlプログラムを書き直し始めました。私はすでに自分の作業コピーに対していくつかのコミットを実行しましたが、実行する必要があったのであれば、実行する代わりに実行する必要があるのではgit pullないかと考えていgit rebaseました。

私は自分がやるべきだとほぼ決心しましたがgit rebase、その効果を達成するために、あるいはそれが可能であるとしても、リポジトリを作り直す方法がわかりません。

コミットを削除する方法を教えてください。

つまり、あたかもそのコミットをdelete行わなかったかのようであり、将来プッシュを実行しても、変更はリモートブランチにプッシュされません。

git helpを読みましたが、使用すべきコマンドはですgit reset --hard HEAD。これは正しいです？

Our project has been using Git for a week or so now, and we're all enjoying it a lot (using it in a tight collaborative group turns out to be quite a different Git experience). To keep things as simple as possible, we do not do any rebasing or history modifications. But we did make a few mistakes in the first week. A few commits were made that shouldn't have been done, and we managed to merge a feature branch into the wrong integration branch (1.1 instead of 1.0). And we didn't find out about these things until they were long into our history.

Now I see a lot of warnings about rewriting history, but I'm not really sure I understand the dangers involved. We use a shared bare repository, and all branches are pushed there for backup.

I would expect that if you rewrite history (say remove a commit), the full list of subsequent commits will "lose" that commit (and maybe not compile/work). I would also expect that if this happens I could actually choose to fix this at the top of history (and just leave that part of history as non-compiling).

• If I rewrite history (and everything compiles/works in all affected branches), will my co-workers need to do any special commands? (In other words, will they "know that I have done it" if I did it well?)
• Will any users with local changes that I do not know about be eligible for merge failures on git pull?
• Am I missing anything essential here?

Any references to articles/tutorials on this subject would also be really nice.

公開する前にブランチ内のコミットを再編成したため、コミットのタイムスタンプの順序が混乱しました。私はむしろ、それらすべてが今日であって、その間に数秒しかないことを望んでいます.

もちろん、これらのタイムスタンプも正確ではありませんが、これは物事が公開される時期であるため、時間的に混乱した歴史よりもそれを好みます.

では、リベース中に新しいタイムスタンプを作成するように git に指示するにはどうすればよいでしょうか?

私は現在、別のリポジトリのマスター ブランチに基づいて、単一のブランチを持つ github リポジトリを使用しています。github ブランチは私の作業のバックアップであり、プルすることを意図したものではありません。そのため、マスター リポジトリからリベースするときにその履歴を書き直すことに問題はありません。

私の問題は、クリーンな履歴が必要なことです。履歴が分岐する場合、それはできません。これは、プッシュ (最初の作業) + リベースを行うと発生します。2 回目のプッシュは拒否されます。

ブランチを削除してからプッシュしようとしましたが、これにはレポのドロップ作成を行うという厄介な副作用があり、これは遅いです。

この問題にどのようにアプローチすればよいですか？