私たちは、私が説明することができない奇妙なgitの動作に気付き始めました。誰かがコミットを行い、後で（通常はマージ後に）、コミットのコード行のいくつかが元に戻されます。これはコミット全体ではなく、ファイルの一部だけに影響する可能性があります。また、正常にマージされた後に発生するようにも見えます（つまり、矛盾が解決されなかった場合）。gitコミットされたコード行が消える
ファイルの一部が変更されたときのように、これが目立つこともあります。それ以外のときは、より微妙なことがあります。それは意図的なものではなく、影響を受けた人々が簡単な説明を提供できるrebase、commit amend、revertなどのものを使用しているようには見えません。もちろん、消えるコードは、新しいコミットでは変更されなかった古いコードです。
紛らわしいマージの際に、以前のコミットの一部をgitで上書きできる方法はありますか？
チームメンバーは、マージする準備ができているときに、コミットをsquashにすることがあります。開発の過程で、多くのコミットを行い、かなり有効なgitの歴史を持つことは役に立ちます。
あなたのブランチをマスターにマージする時間が来たとき（もちろん、同僚があなたのPRを見直しました：ウィンク:)コミットを1つにすることを選ぶかもしれません。大規模なチーム。
あなたのgitのログをチェックしていることを行うことができます。あなたのEDITORはそれぞれがロードされるドキュメントごと
git rebase -i HEAD~4
コミット：
git log
次にあなたが一つに結合したいコミットを選択しますそれはメッセージです。エディタのプロンプトに従います。
pick 01d1124 Adding license
pick 6340aaa Moving license into its own file
pick ebfd367 Jekyll has become self-aware.
pick 30e0ccb Changed the tagline in the binary, too.
# Rebase 60709da..30e0ccb onto 60709da
#
# Commands:
# p, pick = use commit
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
#
一部のチームはthis particular workflowに従い、チームメイトがこれをやることを好むが、これに対して議論がある。
なぜ私はその答えに投票したのだろうか、それは起こりうる完全に有効なことだ。 –
gitログを参照して、行がいつどのように消えるかを調べましたか？ 2つの親コミットを投稿し、消滅したテキストに気づいたところで結合をコミットできますか？ –
これらの欠落している行の中で比較的ユニークな例を見つけ、 'git log -Gphrase'を使用して、その中にそのフレーズを含む行を追加または削除したすべてのコミットのリストを表示します。あなたの検索範囲を絞り込む必要があります – LightBender
git mergeを再帰的戦略で使用すると、変更を上書きすることはできますか？（https://stackoverflow.com/questions/45453017/can-changes-be-conflictless-overwritten-when -using-git-merge-with-recursive-stra） – max630