問題タブ [git-amend]

私たちのチームは git サブモジュールを使用していますが、プルでいくつかのエラーが発生しました。これは、最近更新したにもかかわらず遅れていることを示しています (それ以来、リモート コミット/プッシュはありません)。これは、次の 2 つのシナリオで発生します。

1. HEADサブモジュールで切り離されている、または
2. 使用時git commit --amend。

これらのことが起こったシナリオを示してみます。私の質問は、特定のエラーがどこにあるのか、そしてそれらを修正するための簡単な方法（私たちの汚いハックよりも優れている）を知っている人はいますか?

シナリオ 1 - 切り離されたHEAD

1. 次のいずれかを発行します。
   1. git clone --recursive $REPO $DIR
   2. git sfe 'git pull origin master'
   3. git submodule update --recursiveHEAD- 孤立した状態になりがちなので、実際にはあまり使用していません
2. masterを使用して、すべてのブランチがオンになっている(または少なくとも切り離されたHEAD状態ではない)かどうかを確認しますgit sfe 'git branch'。そうでない場合は、 を発行しgit sfe 'git checkout master'ます。(現在、マージの必要性を最小限に抑え、起動して実行するために、全員 (〜4 人) が master で開発しています)
3. detachedHEADにいる場合は、変更を加えてから (ステージングされていないファイルが作業ディレクトリにとどまるように) に切り替え、masterそれらの変更をステージングしてコミットし、プッシュを試みます。Git は、遅れているためプルする必要があると言います。これは次の方法で修正できます。
   • 「ねじ込み」と言って、完全にクリーンなスーパーモジュールをチェックアウトし、 detachedHEADにいないことを確認し、そこから作業します
   • リビジョン番号を取得しgit checkout master、次に a を発行して、git merge $REV現在の変更を再マージするという苦痛を経験し、そこにあると思われる過去の変更と競合します。

シナリオ 2 - コミットの修正

1. これにはあまりありません。私は自分で開発し、 を発行しgit commit --amend、それらの変更をプッシュしようとします。ただし、これを行うと、遅れているためマージする必要があることがわかります。私がそうすると、現在のすべての変更を過去のリビジョンと再マージするという苦痛なプロセスが再び発生します。
   • これは、もはやコミットではないコミットに基づいたものをプッシュしようとしているためHEADですか?

注:git sfeのエイリアスですgit submodule foreach --recursive(マゾヒズムのためだけに、ネストされたサブモジュールがいくつかあります [というか、コードを分離できるようにする必要があり、サブサブモジュールの配置が理にかなっています])

コミットの直後にファイルに変更を加えてから実行git commit --amendしてからすばやく実行するという間違いを犯すことがよくあります。git push -f origin master

問題は、明らかに、私が走ったことがないということgit add foo.mdです。したがって、私の修正は、実際にはコミットされたコードのいずれも修正しませんでした。

質問は：変更なしでコミットを修正するときにgitが警告しないのはなぜですか？さらに良いことに、なぜそれが正常に完了するのですか？特定のコミットのタイムスタンプを変更する際の「タッチ」のように動作するだけですか？

特定の git コミットが修正されないように保護する方法はありますか?

私が考えられるのは、「修正不可能な」SHA のリストに対して SHA をチェックする pre-commit フックを作成することだけです。標準/より良い方法を知っている人はいますか?

ありがとう。

時々、同じメッセージを使用してコミット修正を行っていることに気付きます。

通常、私は次のことを行います。

1. ステージング領域に変更を追加します。
2. するgit commit --amend。
3. テキストエディタが開くのを待ちます。
4. 保存して閉じます（メッセージを変更せずに）。

とにかく、コミットメッセージを変更したくないことをgitに伝えることはできますか（テキストエディタを開いてメッセージを保存する手順をスキップします）？好き：

1. ステージング領域に変更を追加します。
2. 別のメッセージを要求せずに、ステージング領域を最後のコミットに修正するようにgitに指示します。

を実行することで、gitがテキストエディタを起動するのを回避できることを私は知っていgit commit --amend -m "<message>"ます。しかし、この方法では、メッセージを再入力する必要があります。

私は Gerrit を初めて使用し、新しい変更が送信されたときに新しいパッチを作成したいと考えています。このガイドでGerritをセットアップしましたhttps://review.typo3.org/Documentation/install-quick.html

次に、http: //gerrit.googlecode.com/svn/documentation/2.0/user-changeid.htmlを使用して新しいパッチを作成しChange-Id、コミット メッセージの下部に行を追加しようとしました。

しかし、新しいパッチセットではなく、新しい変更を取得しています。誰でも私を助けることができますか？

ありがとう

コミットをプッシュしたところ、コミットメッセージを変更する必要があることに気付きました。

だから私のローカルレポで私はした：

しかし、これをプッシュしようとすると、大量のエラーメッセージが表示されました

メッセージの修正方法が間違っていたのでしょうか? 結局、すべてのリポジトリをリセットしてから、新しいメッセージで再度コミットする必要がありました。

だから私の質問は、すでにプッシュされたもののコミットメッセージを修正する適切な方法は何ですか?

この一連のコミットを考えてみましょう。

ブランチから始めて、時々からfoo新しいブランチを作成します。今、ブランチで commit に取り組んでいると、 commit を間違えたことに気づきました。それで、編集のためにコミットを実行して開きます。変更を加えてステージングし、実行します。barfoohbarcgit rebasecgit rebase --continue

今、私のbarブランチが更新されました。ただし、fooブランチはまだコミットの元の欠陥のあるバージョンを指していcます。

特定のコミットへのポインターを含むすべてのブランチが識別され、一度に 1 つずつリベースされる、レポ全体のリベースを実行する方法はありますか?

私は手動の方法を知っています-fooをリベースし、新しいSHAを挿入/チェリーピックしますが、どのブランチがコミットを参照しているかを知る必要があります。しかも手作業が必要です。

それらが に存在することは知っていますがgit reflog、コミットをリモート リポジトリにプッシュした場合、修正してからgit push --force(警告:pushing --forceリモート リポジトリへの送信は通常避ける必要があります)、上書きしたコミットはどこかに存在しますか?

5 つのファイルをステージングしてコミットし、それを gerrit にプッシュしましたが、それが git にマージされる前に、そのうちの 3 つを更新してから、最後のコミットに git commit --amend し、再度 gerrit にプッシュした場合は、この 2 番目のパスを実行します他の 2 つのファイルに更新が含まれていますか?