元のSHAコミットコードを保持したまま、フェッチされたリモートでコミットを選択したいと思います(現在のブランチは、以前の状態にリセットしたこのリモートに基づいています)。
5 に答える
git SHAハッシュは、さまざまな情報から計算されます。
- それが参照するツリー。基本的に、コミットが表示されるブランチのリポジトリの現在のコンテンツ。
- 親コミットのSHA 。
- コミットメッセージ。
- 作成者情報:名前、電子メール、タイムスタンプ。
- コミッター情報:名前、電子メール、タイムスタンプ。
ツリー、コミットメッセージ、作成者、およびコミッターの情報がまったく同じになるように厳選されたコミットを編集した場合でも、親コミット(またはマージコミットを処理する場合はコミット)のSHAは常に異なります。したがって、チェリーピックの後に同じSHAハッシュを生成することはできません(SHAの衝突が見つからない限り;))。
SHAコミットハッシュは、リポジトリの状態から作成され、コミットの時点までの履歴全体を使用します(ブランチは含まれません)。つまり、履歴全体が同じでない限り、チェリーピッキングの元のハッシュを保持することはできません。その場合、チェリーピッキングは意味がありません。
他の回答に対するあなたのコメントによると、私はあなたが単にいくつかのリモートコミットにリセットしたいと思うと思います。これを行うために使用できますgit reset --hard <SHA>
。警告:これにより、作業ディレクトリ内の(コミットされていない)変更がすべて破棄され、このブランチで行ったすべてのコミットにアクセスできなくなります。
これがあなたが望んでいることではない場合(またはあなたが確信していない場合)、あなたがしたこと、あなたがしたいこと、またはあなたが達成しようとしていることをより明確に説明してください。
インタラクティブリベース( "git rebase -i")に移動し、HEADに追加する正確なリビジョンを最後に新しいエントリを貼り付けます。
例:
インタラクティブなリベースセッションを開きます。
$ git rebase -i HEAD~4
画面に次のようなものが表示されます。
pick efdd0ece Linked how to make a pull requests in README
pick 790a3be8 adjust pytest pins to fix testing infra
pick 5bb90d8f drop 3.4 support
pick 839dc8ba v2.22.0
pick b97fb61a Print the type of the password instead of the password itself
現在のHEADが最後のエントリです。先頭に追加する正確なリビジョンを使用して、新しいエントリを下部に追加します(「選択」してリビジョンを追加するだけです。説明は不要です)。
pick efdd0ece Linked how to make a pull requests in README
pick 790a3be8 adjust pytest pins to fix testing infra
pick 5bb90d8f drop 3.4 support
pick 839dc8ba v2.22.0
pick b97fb61a Print the type of the password instead of the password itself
pick 2a173c2a6491aae0772640ba7946a08315d18eb8
保存して閉じます。その正確なリビジョンがあなたの頭になります:
$ git log --oneline | head -n 6
2a173c2a Some commit
b97fb61a Print the type of the password instead of the password itself
839dc8ba v2.22.0
5bb90d8f drop 3.4 support
790a3be8 adjust pytest pins to fix testing infra
efdd0ece Linked how to make a pull requests in README
他の回答で述べたように、あなたはまだ規則に従わなければなりません。これは、まったく同じブランチ、親、およびコミッターがある非常に狭い場合にのみ機能します(たとえば、コードレビュー中心のプロセスで、開発者がそれらをプッシュしてプッシュできるコミットの束がどこかにキューイングされている場合など)必ずしも最初にリポジトリに送信せずにそれらを停止します); 実際には、タイムスタンプだけが変更された可能性がある場合に限ります。この場合、タイムスタンプを変更しないように強制するために、同じリビジョンを強制することができます。
他のほとんどの場合、親は通常異なります。これだけで、特定の改訂を強制するというあなたの夢は死んでしまいます。タイムスタンプ以外の要素のいずれかが異なる場合、Gitは常にリビジョンを修正して正しくします。
以前の回答で言及されていなかったので、--ff
フラグを追加することで、コミットの親の上でチェリーピッキングしている場合、元のSHAを保持することが実際に可能であることに注意してください。