1

私は何か悪いことをしました..私は自分が何をしたのかわかりませんが、親がいない状態で2つのコミットがあります。私の知る限り、私は最初のコミットである1つだけを持っていることになっています。

私が責任を負うときはいつでも、ファンキーなコミットが2139f47をコミットする前にすべての変更が行われます。

これは私のreflogのファンキーな部分です：

...
49d0d22 HEAD@{313}: commit (merge): unused questions widget removed
2139f47 HEAD@{314}: commit: unused questions widget removed
e548c10 HEAD@{315}: commit: unused questions widget removed
e7d174b HEAD@{316}: pull: Fast-forward
...

内部リンクは次のようになります。

  HEAD
   |
  ...         e548c10
   |             |
49d0d22 -----+   |
   |         |   |
2139f47     e7d174b
   |           |
  nil         ...
               |
            initial

マージコミットオブジェクト（49d0d22）の内容は次のとおりです。

tree c3989e79c49df4b141b080502192bf0be0f67195
parent 2139f479dac242ad2ef757519aef77f3003ca996
parent e7d174bef4ab7e89b96f8c3de3551d0b760c80f8
author Michael Andersen <***> 1345190024 +0200
committer Michael Andersen <***> 1345190024 +0200

unused questions widget removed

親のないファンキーなコミット（2139f47）の内容は次のとおりです。

tree 4cfebc6b5a2a525bc255e4e095008b6aa8b106cc
author Michael Andersen <***> 1345189769 +0200
committer Michael Andersen <***> 1345189918 +0200

unused questions widget removed

オブジェクトが指しているように見えないコミットの内容（e548c10）は次のとおりです。

tree 0ae0960fccee7faec86ce7a82dd30af70f9c225a
parent e7d174bef4ab7e89b96f8c3de3551d0b760c80f8
author Michael Andersen <***> 1345189769 +0200
committer Michael Andersen <***> 1345189769 +0200

unused questions widget removed

だから私の質問は：

ファンキーなコミットを切り取ることができますか？そして、これは私の仲間のコーダーの起源とローカルリポジトリにどのように影響しますか？

- - 編集 - -

いくつかのコミットオブジェクトを失うことは気にしません。私が見ているように、私は2139f47とe548c10を切り取る必要があります。それ、どうやったら出来るの？

4

2 に答える 2

2

次のことができます。

  1. と同じツリーを使用してコミットを作成します49d0d22が、親は1つe7d174bです。これは、毎日使用されない「配管」コマンドを必要とするステップです。

  2. の子孫49d0d22をこの新しいコミットにリベースします。これにより、HEAD再び使用できるようになります。

  3. 非早送りプッシュを実行しようとしていることを同僚に警告します。（レポが非早送りプッシュを拒否するようにカスタマイズされている場合は、レポ管理者に相談して一時的に有効にしてください。）プッシュを実行します。

  4. 同僚がツリーをで更新していることを確認してください。git pull --rebaseそうすれば、同僚は古いものとのマージを決して試みませんHEAD。これを確認するgit merge-base HEAD 49d0d22には、プルの後に実行するように依頼します—空になるはずです。

これらの手順を実装するコマンドは、次のようになります。

# 0.
git checkout master # or whatever your working branch is called

# 1.
commit=$(git commit-tree -m "unused questions widget removed" -p e7d174b 49d0d22:)

# $commit should now identify the new commit; you should be able to see it
# with git log $commit or any other git inspection tool.

# 2.
git rebase 49d0d22 --onto $commit
# now your HEAD should be in a valid state.
# git merge-base HEAD 49d0d22 should output nothing

# 3.
git push origin master

git checkout master # or whatever your main branch is called

コミットに関しては、e548c10無視してください。それを参照しているローカルブランチとリモートブランチを削除し、他の人にもそれを無視するように指示します。このコミットはまったく言及していないため2139f47、このステップは上記の手術とは完全に独立しています。

于 2012-09-22T07:29:12.627 に答える
1

いくつかの移植片または置換を使用して、レポに適切な外観（リンケージ）を与えてから、フィルターブランチを使用して永続的にします。

これは、それらのファンキーな部分が、他の部分に依存してまだ公開されていないことを前提としています。

しばらく前に編集してください私はどのように-git-grafts-and-replace-differ、are-grafts-now-deprecated？2つのテクニックについて。

実際には、移植片のセットアップが簡単であることがわかりました。これは単にコミットのリストです。コミット内にリストされている既存の親の代わりに、尊重したい親のペアです。

これは、たとえば、不正なコミットをバイパスするペアでコミットチェーンを切断できることを意味します（すべてのコミットは単なるスナップショットであることを忘れないでください;-)。

あなたの場合、必要なリンクをグラフトファイルに追加することで、コミットをコミットチェーンのどこかにあるように見せることができます。接ぎ木（ライン上の2つの親）を使用して「偽の」マージを作成することもできます。

したがって、変更したいリンクを設定したリスト（移植ファイル）を作成すると、希望どおりに表示されます（のように見えます）。その時点で、おそらくそれを永続的にしたいと思うので、単にgit filter-branchそれらの部分を書き直すために実行してください。同僚が「驚かない」ように、何が起こるかを知っていることを確認してください。

于 2012-09-21T21:27:34.443 に答える