2

ここで少し状況があります。開発ブランチをリベースしてプッシュしようとしたのですが、拒否されました (非早送り)... 理由がわからないので、あなたに来ました...

私がしたこと:

git checkout dev
git rebase G
# Here, I had to manually merge some files

# Result (in gitk) was :
#       A---B---C remote/dev   A'---B'---C' dev
#      /                      /
# D---E---F------------------G---H remote/master

git push remote dev

私のプッシュが「非早送り」であり、拒否された理由は何ですか?

4

1 に答える 1

6

rebase を実行したため、早送りではありません。rebase一連のコミットを取得し、それらから新しいコミットを作成します (コミット DAG の別の場所にある可能性があります)。git rebase実際に実行する前に、実行することのすべての意味を理解していることを確認してください。早送りできないことは、これらの影響の 1 つです。

公開された履歴をリベースすることは、一般的に悪い考えと考えられています。本当にブランチをリベースしてプッシュする必要がある場合は、-fフラグを git push に渡すか、refspec の先頭に+( git push remote +dev) を追加します。

あなたのリポジトリのクローンを作成し、そのブランチで作業していた他の人が同じリベースを行う必要があります。そうしないと、次に貢献者の 1 人からマージするときに古い履歴をマージすることになります。


早送りについて詳しく説明します。

あなたのグラフから、これは簡単に見ることができます。早送りは基本的にコミットを履歴に追加するだけです。各コミットは、そのコミット ハッシュによって一意に識別されます。コミット ハッシュは、コミットの内容とコミットの履歴に対して計算されます。これは、異なる祖先/親を持つコミットは、定義により異なるハッシュを持つことになることを意味します。

多数のコミットを取得し、それらを DAG 内の別の場所にプラグインすると、別の履歴が記述され、新しいコミット ハッシュが取得されます (コミット時間も更新されましたが、ここでのポイントではありません)。したがって、もはや追加専用ではないため、早送りすることはできません。さらに、結果をリベースしてプッシュした後は、(reflog に頼らなければ) 古いコミットにアクセスできなくなります。

これについて考える別の方法: プッシュは古い ( remote/dev) ブランチにコミットを追加しませんが、別の場所にコミットを追加します (commit G)。

于 2012-08-29T10:01:31.563 に答える