34

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.

4

2 に答える 2

22

必読はGit User's Manual のProblems with rewriting historyです。

履歴を書き直した場合 (影響を受けるすべてのブランチですべてがコンパイル/動作する場合)、同僚は特別なコマンドを実行する必要がありますか?

彼らはそれを認識し、Git は不確かな言葉で何かが間違っていることを伝えます。予期しないエラー メッセージが表示され、結果として生じるマージの競合を解決しようとする過程で、誤って以前のコミットを元に戻す可能性があります。この問題は実際のメッセージを作成します。何が起こるか知りたい場合は、リポジトリの一時コピーでいつでも試すことができます。

私が知らないローカル変更を行ったユーザーは、 git pull でマージの失敗の対象となりますか?

絶対に、上記を参照してください。

ここで重要なものが不足していますか?

(ほぼ) あらゆる犠牲を払って履歴を書き換えるのを避けてください!

于 2009-09-29T07:08:58.057 に答える
8

他の回答コメントで述べたように、実際には各コミットは一意であり、履歴を書き換えると新しいコミットが作成されます。

木の枝を切り落とし、すぐに新しい枝を伸ばすようなものと考えることができます。それらは同じように見えるかもしれませんが、そうではありません。はい、ブードゥーマジックです。この類推では、元に戻すことは、倒れた枝を丸太で支えるようなものであり、倒れることなく成長します。

これにより、履歴を書き換える正当な理由がいくつかわかります。

  • 公開する前にプライベート リポジトリをスリム化します。たとえば、新しいローカル プライベート ブランチを作成し、テスト、テスト、書き換え、プッシュします。
  • 公開する前にプライベート リポジトリから機密データを削除します。

それらは、Greg がすでに言ったことをすでに明らかにしています:リポジトリが公開されている (プッシュされたコミット) 場合、履歴を書き換えると全員が台無しになる可能性があります。良い習慣を維持するためだけに、プライベートリポジトリでも絶対にそれを避けることを私が提唱する理由: したがって、履歴の書き換えは絶対に避けるべきです (これは、それを行う前に十分な考慮を払うことを意味します: 長所を強調することを意味します)そして短所！）

そして、少なくとももう 1 つの哲学的で見過ごされている理由があります。書き換えられた履歴はデータの損失です。確かに、git 履歴revertは 1 つよりも乱雑に見えるかもしれませんreset。しかし、適切に記述されていれば、すべての「ごちゃごちゃ」を別々のブランチに隠すことができ、どの時点で復帰が行われたかを正確に確認できます。そして、なぜそれが行われたのかについての理由や証拠があっても。

木の例えに戻りますが、支えとなる丸太を取り除いても、元に戻された枝は曲がりくねった成長カーブを見せ、美しいです!

于 2013-09-17T20:16:55.540 に答える