2012-02-21 7 views
2

私はまだリベースの影響とGitの履歴の書き換えを理解しようとしています。 1年分の価値あるソースコードの履歴を持つgithubのリポジトリRを想像してみてください。それが惑星の唯一のコピーだとしましょう。回復できないgit push?

リポジトリを複製し、変更を加え、それらをプッシュバックすることで、そのリポジトリが永久的に失われることがありますか?私は知っている、いくつかの奇妙なシーケンスのrebase、削除、プッシュ?もしそうなら、即座に不可逆的になるようなシーケンスがありますか(ガベージコレクション後に1ヶ月程度後に起こるのではなく)?

答えて

2

デフォルトでは、非早送りプッシュはサーバーによって拒否されます。しかし、git-push man pageから、あなたは潜在的に破壊的なプッシュ操作を受け付けるようにサーバーを強制する手段を見つけることができます:

--force

-fは、通常、コマンドは、リモートを更新することを拒否しますrefは、それを上書きするために使用されるローカル refの祖先ではありません。このフラグはチェックを無効にします。 リモートの リポジトリがコミットを失う可能性があります。慎重に使用してください。

警告が言うようにが、これはリモートのは、1つまたは複数のコミットを失われる可能性があります。具体的には、これは、宛先ブランチのコミットが別のブランチのHEADから到達できない場合に発生する可能性があります。コミット場合

git clone ... 
edit ... 
git add . 
git commit --amend -m "These changes overwrite origin/master's HEAD." 
git push -f origin master 

しかし、あなただけのタグを付けたり、別のブランチのHEADからアクセスすることが起こっ上書きしようとした、意志をコミット:

はたとえば、次のシナリオは、コミット失うことにサーバーを引き起こす可能性があり紛失しないでください。

+0

だから、おそらくあなたは、すべてこの方法を使用して全体の歴史の中でコミット上書きすることができます。これは、バージョン管理の教義の1つを破りませんか? –

+2

@SteveBennett:はい、技術的には履歴全体を上書きすることができます。技術的には*ソース管理が中断しますが、リポジトリをクローンする人はクローンを使って履歴を復元できるので、実際には問題は起こりません。さらに、Gitを使用する好ましい方法は、プル/マージ要求を使用してコミットをレビューできるようにすることで、与えられたリポジトリにアクセスできるのは1人だけです。 –

+0

どちらも非常に合理的な点です。 –

1

リポジトリに強制的にプッシュすると、AndréCaronが説明したように、いくつかのコミットに到達できない可能性があります。

Githubはリポジトリにアクセスできません(これはまさに標準的なgitリポジトリではないため、これはあなたのビジネスではないためです)。この場合、実際には情報が失われます。

しかし、このリポジトリの効果的な管理者であれば、reflogを参照してフォースプッシュから復旧し、その後ブランチに戻すことができます。

ローカルリポジトリ(強制プッシュを行ったリポジトリ)には、残されたコミットが含まれている必要があるので、それらを復元できるはずです。

+0

オクラホマ - でも私はまだ少し不明です。私のシナリオでは、世界中にリポジトリのコピーが1つだけあり、Githubにあります。だから、悪いフォースプッシュは、(reflogへのアクセスに関する問題のために)コミットを取消不能に失う可能性があります。 –

+0

技術的には、2つのリポジトリがあります.1つはGithubと1つのリポジトリです。 しかし、実際には、Githubリポジトリのようにローカルリポジトリにブランチの状態が含まれないことがあります。だから、あなたはこの非常に奇妙な(しかし可能な)状態でコミットを緩めるでしょう。 –

1

はい、一部の操作は、たとえば、永久に歴史を破壊しようとしている。

git push repo-name +master 

は、ローカルブランチがマスターの歴史を失うと、あなたのマスターレポ(レポ-name)を上書きします。

しかし、あなたの歴史をゴミ箱に最も一般的な方法は、対話型リベースである:

git rebase -i 6bd80e12 

...唯一の外部リポジトリをプッシュされていないコミットでこれを行います。他の人があなたが削除しようとしているコミットに基づいて作業している場合、多くの競合が発生する可能性があります。それが他人と共有されている場合は、あなたの履歴を書き直さないでください。

私は続きを読むにreccomend:

http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html

http://progit.org/book/ch6-4.html

http://book.git-scm.com/4_interactive_rebasing.html

+0

うん、面白い。フレッドとアンドレによって提案されたシナリオとは異なり、これは誤って起こる可能性があります。あなたは歴史を書き直すことを奨励され、変更を共有することが奨励されています - あなたは何とかそれら2つのものを組み合わせることを避けなければなりません。 –

+0

@SteveBennett:「間違って」(リベースが本当に何を誤解しているかのように)、リモートエンドは早送りマージを実行できない場合、プッシュの受け入れを拒否します。コミットを破壊/上書きする方法はたくさんあります。すべての操作は*ローカルで*行われるので、すべて安全です。それは実際に何かを消去する可能性が高い 'git push 'だ。実際に歴史を失うためには 'git push -f'する必要があります。 –

関連する問題