問題タブ [git-amend]

多くのファイルを変更し、それらを Git ステージング領域に追加しました。その後、それらをコミットする前に、前のコミットのコミット メッセージを変更する必要があることに気付きました。そのためgit commit --amend、変更ログを確認せずにコミット メッセージを変更しました。さて、それはステージング領域のファイルを以前のコミットにも追加しました。

以前のコミットを元の形式で作成し、変更したファイルをステージング領域に戻して、それらを個別にコミットできるようにするにはどうすればよいですか?

価値があるのは、最初に変更をコミットしてから、を使用してコミットメッセージの履歴を変更する必要があることに気づきましたgit rebase -i。

git の知識を役立てて、日常的に使用できるようにするには、次の違いは何ですか:

• 元に戻す
• 改める
• ロールバック
• 元に戻す

彼らは何者で、何をしているのか?

リモートの「dev」ブランチがあり、ローカルで作業していました。

コミットメッセージ「my_feature」を使用して「dev」で最初のコミットを行い、ローカルブランチをリモートブランチよりも1コミット先に置きました。

次に、いくつかの新しいものを開発し、 を作成してgit add -u、コミットする準備をしました。次に、以前のコミット メッセージを「my_feature (1/2)」として作り直して、現在のコミット メッセージを「my_feature (2/2)」として作り直し、ローカル ブランチをリモート ブランチよりも 2 コミット先に置きたいことに気付きました。

だから私はgit commit --amend（前のコミットのメッセージを編集するだけだと思って）作成し、「my_feature」コミットメッセージを「my_feature（1/2）」として編集し、...「my_feature（1/2）」というラベルの付いた単一のコミットになりました"すべての変更(最初のコミット + ステージング ファイルの差分) を取得 -- インデックスはクリーンになりました。

それで、私が正しければ、私のコマンドは実際にコミットを行い、ステージングファイルもコミットし、単一の（マージされた？）コミットを生成しましたか？

Git がそのようなことをするとは思っていませんでした。古いコミット メッセージを現在のステージング ファイルとマージするのではなく、古いコミット メッセージを編集したかっただけです。（今考えると、rebaseもっと良かったかもしれません。）

コミットできる理由は理解git commit --amendできますが (コミット メッセージを編集したいだけでも)、Git がコマンドを使用して 2 つのコミットを 1 つにマージする方法を理解するのに問題がありますcommit。

誰でも私にこれを明確にすることができますか？

私は、レビュー担当者がレビュー済みのブランチの上に空のコミットを追加し、開発者に送り返すローカルコードレビュープロセスを持っています。

その後、開発者はそれを canonical にプッシュします。

最後のコミットがコードがレビューされていることを示しているかどうかを確認し、ブランチのすべてのコミットのコミット メッセージに「PEER-REVIEWED」という単語を追加してから、Canonical にプッシュする事前プッシュ フックを作成したいと考えています。

(使用: 正規のコミットを確認し、レビューされているかどうかを確認できます。レビューされている場合は、「PEER-REVIEWED」という単語が含まれています。)

1. アプローチはどの程度実用的ですか？
2. プッシュされるすべてのコミットのコミット メッセージに単語を自動的に追加するにはどうすればよいですか。

ありがとう！

最近、10 個のファイルを含むコミットを行いました。ファイルの 1 つはコミットされていないはずです。それには、他のユーザーには機能しない私のローカル テストの変更が含まれています。

以前のコミットからそのファイルをチェックアウトし、元のファイルとして再コミットしてから、変更をローカルに再適用したいと思います。

git revert良さそうに聞こえますが、コミット内の 1 つのファイルではなく、コミット全体のようです。gitのおしゃべり/ログを最小限に抑えながら、これを行う良い方法はありますか? おそらく以前のコミットを修正しますか？

それが役立つ場合、これはまだプッシュされていません。

Git には、中央リポジトリでコミットを修正できるようにするオプションがありますか (たとえば、説明、コミッター名、または彼/彼女の電子メール アドレスを変更するため)、履歴全体を消去することはできません。

私が理解しているように、デフォルトでは両方が許可されています（receive.denynonfastforwards = false）。

現在、プロジェクトに取り組んでいます。いくつかの特定のプライベート フォルダーを除外しながら、完全な情報 (作成者など) を含む日々のコミットをオープン ソース化したいと考えています。

ブランチ マスターで A/file1 と B/file2 をコミットするとします。B フォルダーをフィルター処理して GitHub にミラーリングしたいとします (このコミットには A/file1 のみが含まれます)。

私がこれを行うことを考えていた 1 つの方法は、次のようなリモート アップデート フックです。

• newref によって追加されたすべての新しいコミットを一覧表示します (lastfoundcommit..newref としましょう)
• これらのコミットを 1 つずつ修正して (lastfoundcommit から newref まで)、不要なファイルを削除します。
• その過程で、ローカルの master-filtered ブランチが作成される場合があります (ローカルにあると便利な場合)。
• このブランチを公開リポジトリにプッシュします
• 次のプッシュで「lastfoundcommit」を簡単に計算できるように、プライベート コミットとパブリック コミットの間でコミット ID のマッピングを維持する

理想的には、両方の方向に進むことができます (つまり、github ブランチとプル リクエストをインポートし直して、プライベート リポジトリの上に自動的に、または簡単なプロセスで "リベース" できると便利です。おそらくそれほど難しくはありません)。おそらく単なるリベースです）。

これは、サブディレクトリを抽出するのではなく、代わりにさまざまなファイルをフィルタリングすることを除いて、git-subtree ができることと多少似ています。

それは実現可能だと思いますか？または他の提案はありますか？(多分 git filter-branch? または私を助けるかもしれない他の既存のツール/スクリプトに基づいていますか?)

注: サブモジュールは実行可能なオプションではありません。また、「プライベート」ファイルのリストは、時間の経過とともに拡張/変更される可能性があります。

これについての私の理解を修正するためにオープンしましたが、なぜこれが起こるのかわかりません。

git を使用している場合、ファイルに変更を加えてからコミットすると、ファイルが変更されたために新しいハッシュが取得されることを理解しています。

私の理解でgit commit --amendは、最後のコミットに変更を加えることができます。

これで、コミット メッセージを変更するとハッシュが変更されることがわかりました。

しかし、何も変更せずに保存してエディターを終了すると (変更が必要だと気が変わった可能性があります)、ハッシュが変更されるのはなぜですか? すべてのファイルとすべてが同じですが、保存しました。コミットのgit log時刻が変更されていない場合、コミット ハッシュが異なることを除いて、同じ時刻、同じメッセージ、同じファイルでログに 2 回表示されます。

変更が行われていないのに、なぜ変更されるのですか??