Git の競合問題を解決し、Idea でマージコードが消失する問題を解決する

Git コマンドの全シリーズ

1 Idea で git を使用する場合の小さな問題とヒント

Idea を通じて GitLab や GitHub などのプラットフォームからコードを直接プルできます。

File - New - Project from Version Control

ここに画像の説明を挿入します

输入对应项目的URL即可

ここに画像の説明を挿入します

上記のヒントで引き抜くことができない場合は、下の図のオプションを確認してください。

2 紛争問題を解決するためのアイデア

2.1 デモの競合 (GitLab)

①まず、GitLab または任意のコードホスティングプラットフォームで独自のウェアハウスを作成します

git clone 仓库的URL

上記のコマンドでリポジトリのクローンを作成します

②自分のプロジェクト内に任意にクラスを作成
ここに画像の説明を挿入します

③ ローカル倉庫に提出し、リモート倉庫にプッシュします

ここに画像の説明を挿入します
④その後、リモートライブラリ内のコードを任意に修正します

ここに文を追加しました

ここに画像の説明を挿入します

⑤ローカルコードを変更してリモートウェアハウスにプッシュしてみる

現時点では、ローカルコードがリモートライブラリの最新バージョンではないため、バージョンの競合が発生します。

ここに画像の説明を挿入します

⑥紛争が発生する
ここに画像の説明を挿入します

2.2 Git バージョンの競合を解決する

①この時点でリベースを選択します（企業標準で要求されているため、リベースを選択する必要があります。直接マージすると一連の問題が発生する可能性があります）

以前はデフォルトのオプションとして rebase を使用したため、ここでは選択をスキップしました。

ここに画像の説明を挿入します

② 独自の要件に応じて運用する
ここに画像の説明を挿入します

Accept Yours 就是直接选取本地的代码，覆盖掉远程仓库的
Accept Theirs是直接选取远程仓库的，覆盖掉本地的
Merge  自己手动进行选择，修改

③通常は手動でMegeを行います。
ここに画像の説明を挿入します

ここの左側の部分はローカルウェアハウスのコード、右側の部分はリモートウェアハウスのコード、そして中央の結果が変更したものです。

その結果、左下隅の AcceptLeft および Accept Right は、実際には前の Accept Yours および Accept と同等になります。

右下隅の「適用」をクリックするとマージが確定し、「中止」をクリックするとマージがキャンセルされます。

結果にマージするコードを変更した後、「適用」をクリックするだけで、この時点で競合は解決されます。

詳細なドキュメント:
https://www.cnblogs.com/newAndHui/p/10851807.html

2.3 リベースに失敗しました

リベースが失敗した場合:
ここに画像の説明を挿入します
解決策:

$ git add .(只要有修改都需要git add . 或者git add 具体的文件)
$ git rebase --continue
Applying: 【HCF】*******************
$ git push origin ******************************
git rebase --continue 就相当于 git commit

3 Git エラーレポート

Git の競合があったときに、誤ってマージ操作をクリックしてしまい、ローカルとリモートのウェアハウスのコードが
どこからともなく消えてしまい、src フォルダーが削除されてしまいました。

3.1 Git でマージを実行するとコードが消える

①git logから指定したファイルを変更したコミットを調べる
現在のプロジェクトファイルは削除されていますが、プロジェクトのコード構造からsrcフォルダは元々存在していたことが推測できます

すべての履歴レコードでこのファイルの処理を検出してみます。使用するコマンドは次のとおりです。

git log --stat --full-history --simplify-merges -- src

ここに画像の説明を挿入します
上記のコマンドは、このフォルダー内の変更を含むコミットを表示します。出力から、857 で終わるコミットで、誤って 11 行のコードを削除したことがわかります。

②本バージョンに切り替えることで

git checkout 982918cd36668686c2644decbf0a0e4988283857

ここに画像の説明を挿入します
次にプロジェクトに戻ると、以前のコードが復元されていることがわかります。

なぜそのような状況が起こるのでしょうか？
分析: https://cloud.tencent.com/developer/article/2033888

3.2 Git pull --rebase エラーレポート

git pull --rebase报错

error: cannot pull with rebase: Your index contains uncommitted changes.
error: please commit or stash them.

これは、送信されていないローカル変更があるためです
。送信する必要がある場合は、 git add および git commit を実行できます。
変更を送信する必要がない場合は、一時ストレージとして git stash を使用できます
。解決手順:

プロンプトに従って次の操作を実行します

git スタッシュ
git pull --rebase
git スタッシュポップ

または：

git add *
gitコミット
git pull -rebase

それから提出できます
ここに画像の説明を挿入します

3.3 git clone または commit エラー: errno 10054 または errno 10054

エラーログ：

致命的: 'https://github.com/AliyunContainerService/k8s-for-docker-desktop.git/' にアクセスできません: OpenSSL SSL_read: 接続がリセットされました、エラー番号 10054

または

致命的: 'https://github.com/xxx/autowrite.git/' にアクセスできません:
github.com ポート 443 への接続に失敗しました: タイムアウトしました

理由：

git がプロジェクトをプルまたは送信するとき、途中に git の http および https プロキシが存在しますが、ローカル環境自体には SSL プロトコルがあるため、git の https プロキシをキャンセルするだけです。それが機能しない場合は、http プロキシをキャンセルしてください。。

もう 1 つの理由は、現在のプロキシネットワークの速度が遅すぎるため、成功することもあれば失敗することもあります。

解決：

, 次のコマンドを実行して、git 自体の https プロキシをキャンセルし、独自のローカルプロキシを使用します。そうでない場合は、デフォルトで git が使用されます。

//取消http代理
git config --global --unset http.proxy
//取消https代理 
git config --global --unset https.proxy
//重新执行git clone 或git commit

インターネットを科学的に利用してネットワークの問題を解決する

4 拡張:

4.1 git clone と git pull の違い

git clone はローカルにリポジトリを持たず、リモートリポジトリ全体をダウンロードします

Git pull にはローカルリポジトリがあり、新しいコミットデータ (存在する場合) をリモートウェアハウスにダウンロードし、それをローカルコードとマージします。

4.2 マージとリベースの違い

詳細な説明: https://zhuanlan.zhihu.com/p/75499871
https://segmentfault.com/a/1190000038547167

rebase与merge实现，版本提交数风格会呈现不同的效果

リベースは現在のブランチのコミットをパブリックブランチの最後に配置するため、リベースと呼ばれます。あたかもこのブランチをパブリックブランチから再び引き出したかのようです。

例: master から prod ブランチをプルし、いくつかのコミットを送信し、誰かがその開発したものをたまたま master にマージした場合、master にはブランチをプルしたときよりもいくつかのコミットが追加されます。この時点で、あなたの現在のコミットはその人のコミットの後ろに配置されます。

具体的な効果は以下の通りです。

master 初始状态为1，2，3.在此基础上新建一个prod分支
master 提交了4，5.  prod分支提交了6，7.
此时分支状态：master->1-2-3-4-5
            prod ->1-2-3-6-7
在prod上使用rebase master，prod分支状态变成1-2-3-4-5-6-7            
如果merge master，prod分支状态变成1-2-3-6-7-8
        这里的8提交的是4-5合起来的提交
merge之后想回退到你分支上的某个提交就会很麻烦！

4.3 コードをローカルでリモートエンドに送信する

通常、開発中はコミットする前にコミットし、その後リモートウェアハウスをプルして現在のバージョンが最新バージョンであることを確認してから、リモートウェアハウスにプッシュします。

マージ操作の選択
リベース操作の選択

ここに画像の説明を挿入します

4.4 一時コードの一部がリモートウェアハウス (git stash) に送信されない

也可以参考4.9的方法：change list

開発中、コードをマージする必要がある同僚に必ず遭遇しますが、現時点ではローカルでいくつかのコードも作成しており、いくつかの理由 (テストされていません) により、これらのコードをリモートライブラリに送信したくありません。

では、このとき何をすべきでしょうか？git stash の動作
①プロジェクト名を右クリックし、gitを選択し、stashの変更(ストレージ)を選択します。
ここに画像の説明を挿入します
②次にgit pull、リモートウェアハウスから最新のコードをプルしてマージ(マージ)します
。 ③最新のコードを取得したら、unstashして、取得する前にコードを取得します。ローカルで書いた

4.5 git pull オリジンマスター --allow-unpopular-histories

POST git-upload-pack (327 バイト) https://gitee.com/Zifasdfa/graduation-music から * ブランチ master -> FETCH_HEAD = [最新] master -> Origin/master は無関係な履歴のマージを拒否

この問題の主な理由は、ローカル倉庫とリモート倉庫が実際には 2 つの独立した倉庫であることです。リモート github リポジトリのローカルリポジトリをローカルに直接クローンしていれば、この問題は発生しなかったでしょう。

git pull origin master --allow-unrelated-histories

問題を解決します

4.6 git は追加されたファイルを削除します

git は追加されたファイルを削除します

物理ファイルは削除されず、キャッシュからファイルがクリアされるだけです

git rm --cached "文件路径"

[その他] git rm --cache と git replace HEAD の違いは何ですか?
ファイルを削除する場合は、ワークスペースで直接 rm file_name の代わりに git rm file_name を使用することをお勧めします。
ファイルがステージング領域に追加されていてまだコミットされていない場合、そのファイルが不要になった場合は、次の 2 つの方法があります。 1. リポジトリの内容でステージング領域をクリアし、 git restart HEAD を実行しますが、それを次のコマンドで使用します
。 2.ステージング
領域から特定のファイルを削除するには、 git rm --cached xxx のみを使用します。

ファイルがキャッシュから削除されるだけでなく、物理ファイルも削除されます (ゴミ箱にはリサイクルされません)。

git rm --f "文件路径"

ここに画像の説明を挿入します

IDEA を使用している友人の場合:

一時的に保留にすることもできます

コミットするときに、シェルブするファイルを選択し、右クリックして「変更をシェルブ」を選択します
ここに画像の説明を挿入します

スタッシュの変更を選択できます

プロジェクトを選択し、右クリックして git を選択し、stash の変更を見つけます。
ここに画像の説明を挿入します

無視ファイルに直接追加

右击项目 - git - .git/info/exclude

ここに画像の説明を挿入します
3. ロールバックによっても実現できます

図に示すように、誤って README.md を git ローカルリポジトリに追加してしまいました。

ここに画像の説明を挿入します
通过rollback解决：

ロールバックしたいファイルを選択し、「ロールバック」をクリックします

ここに画像の説明を挿入します

README.md が赤色に変わり、ローカルウェアハウスに追加されていないことがわかります。

ここに画像の説明を挿入します

4.7 Idea はローカルコードを指定されたバージョンにロールバックし、同時にそれをリモートに更新します

開発中にこのような問題が発生することがあります。つまり、間違ったコードをリモートウェアハウスに送信し、リモートコードとローカルコードを同時にロールバックしたい場合です。

有两种方法：1、Revert操作  2、利用IDEA的Reset Head指针

方法 1 の元に戻す操作は、新しい送信レコードとして扱われ、送信ログに追加されるため、元の送信レコードが保持されます。（推薦する）

方法 2 の Reset Head ポインターは、元の送信レコードを破棄し、Head ポインターが指定されたバージョンを指すように強制します。

バージョン 1 に基づいてコンテンツを変更し、ローカルウェアハウスとリモートウェアハウスを送信した後、送信されたコンテンツが望んでいたものではないか、完全に間違っていることがわかり、バージョン 1 をロールバックする必要がありました。

① 現在、現地支店と遠隔支店は 2 回目の提出場所にあります。
ここに画像の説明を挿入します

ロールバックしたい履歴バージョンを右クリックし、「元に戻す」を選択します（下の図を参照）。

② この時点で、競合を解決する必要があります。

競合ダイアログボックスが表示されるので、競合ファイルをダブルクリックして競合を解決します。（以下を参照してください）

ここに画像の説明を挿入します

注意：ロールバックが失敗した場合は、送信されていない他のローカル変更がある可能性があります。これらの変更は stash に一時的に保存できます。

your local changes would be overwritten by revert.
hint: commit your changes or stash them to proceed.
revert failed

隠し操作:
ここに画像の説明を挿入します

③競合が解決されると、ローカルは④ローカルでコミットする前の正しいコードに戻り
ここに画像の説明を挿入します
、ログにロールバックレコードが追加されていることがわかり、同時にリモートにプッシュすると、リモートとローカルは同期されています [ ]originリモート

:

この種のロールバックの利点は、「ロールバック」操作を後悔した場合に、ロールバック前のバージョンにロールバックすることもできることです。履歴レコードにはコミットレコードも保持されるためです。

4.8 git でのチェリーピックの使用法

チェリーピック: 最良の選択

マルチブランチコードの場合、コードを 1 つのブランチから別のブランチに移動するのが一般的です。
現時点では次の 2 つの状況があります。

別のブランチを必要とするすべてのコード変更 ( git merge 合并)
一部のコード変更、一部のコミット ( cherry pick )

たとえば、コードリポジトリにはマスターとフィーチャーの 2 つのブランチがあります。

    a - b - c - d   Master
         \
           e - f - g Feature

次に、コミット f を master ブランチに適用します。

# 切换到 master 分支
$ git checkout master

# Cherry pick 操作
$ git cherry-pick f

上記の操作が完了すると、コードベースは次のようになります。

    a - b - c - d - f   Master
         \
           e - f - g Feature

上記からわかるように、コミット f が master ブランチの最後に追加されます。

git Cherry-pick コマンドのパラメータはコミットのハッシュ値である必要はなく、ブランチの最新のコミットが転送されることを示すブランチ名でも構いません。

$ git cherry-pick feature

上記のコードは、機能ブランチの最新のコミットを現在のブランチに転送することを意味します。

4.9 ローカルで変更リストを作成（指定したファイルを送信）

複数のプロジェクトをプルするときに、次の問題がよく発生します。
修改了多个项目，但是只想提交一个项目中的代码その場合は、変更リストを作成できます。

ここに画像の説明を挿入します

たとえば、ここでは DynamicLinkDTO のみを送信したいとします。

その後、ローカルで作成できますchangelist

マウスの右ボタンを直接new changelist
送信したいコードを、先ほど作成したコードに移動します (changelist例:default_change)
「default_change」を選択して右クリックし、「git」を選択してプッシュします。

4.10 ローカルの git ウェアハウスと gitee の git ウェアハウスがありますが、それをマージするにはどうすればよいですか?

git pull origin master --allow-unrelated-histories

または

# 添加远程地址
git remote add origin https://gitee.com/Zifasdfa/ziyi-app.git
git push -u origin "master"

git pulloriginmaster --allow-un relationship-histories: このコマンドは、リモートウェアハウスの master ブランチをローカルウェアハウスの現在のブランチにマージするために使用されます。

–allow-uncategorized-histories パラメーターは、無関係な 2 つの履歴ブランチをマージできるようにするために使用されます。このコマンドは、2 つのウェアハウス間の操作を結合するのに適しています。

git Push -uorigin "master": このコマンドは、ローカルウェアハウスの master ブランチをリモートウェアハウスにプッシュするために使用されます。

-u パラメーターは、次回プッシュするときに git Push を直接使用できるように、上流ブランチを設定するために使用されます。このコマンドは、単一のウェアハウスへのプッシュ操作に適しています。

4.11 Git コミットが遅すぎる

git 設定を見つけて閉じますanalyze code

ここに画像の説明を挿入します

4.12 git スマートチェックアウトと強制チェックアウト

IDEA が 1 つのブランチのコンテンツをコミットせずに変更し、別のブランチに切り替えると、競合が発生する可能性があります。

この時点で、IDEA はスマートチェックアウトまたは強制チェックアウトを選択するように求めるプロンプトをポップアップ表示します。

変更を元のブランチに保持したい場合は、[スマートチェックアウト] を選択します。
強制チェックアウトでは変更は保持されず、別のブランチに切り替えるとコンテンツが消え、元のブランチに戻した場合は元のブランチを取得できなくなるため、無駄になります。

原則: スマートチェックアウトを選択すると、IDEA は最初に stash コマンドを実行してこれらのコミットされていない変更を保存し、次にブランチ B にチェックアウトします。ブランチ B に切り替えた後、これらの変更はスタッシュ解除され、ブランチ A のローカル変更はブランチにもたらされます。 B. .

4.13 メールの不一致の問題

開発中に、github または gitee 上のメールと会社の gitlab 上のメールを行き来することがあります。

会社コードを変更してプッシュするときに次の問題が発生した場合は、次のようになります。

リモート: プッシュ例外: この送信 a84887a5d29a8643fd6ef45904b47f2067dbcc35 は、ローカルクライアントによって設定された電子メールアドレス ([email protected]) が、GitLab で設定した電子メールアドレス ([email protected]) ではないことを検出します。ローカルのとリモートのメールアドレスは同じです！

この時点で、ローカルの git メールボックス構成が gitlab で設定されたものと一致しているかどうかを確認する必要があります。

# 查看git全局邮箱配置
git config --global user.email

# 修改git全局邮箱配置
git config --gloabl user.email yyyss@xxx.com.cn

# 修改私有配置（某个git文件的）
git config user.email ziyi@163.com

その後、もう一度プッシュして、エラーがまだ報告されていることがわかった場合は、コミットで以前のメールボックスがまだ使用されており、新しいコミットが生成されなかったため、新しいメールボックスの使用に失敗したことが原因である可能性があります。修改注释或者增加空行，然后commit即可解决

4.14 現在のブランチの先端が遅れているため、更新が拒否されました

このエラーは通常、ローカルブランチとリモートブランチのコミット履歴が矛盾している場合に発生します。解決策は、ローカルブランチにプッシュする前に、リモートブランチから最新のコミットをプルすることです。

# 1. 切到本地分支
git checkout main
# 2. 拉取远程分支
git pull origin main
# 如果有冲突产生，需要解决冲突后再继续

参考記事：
https://blog.csdn.net/Torey_Li/article/details/87442355
https://blog.csdn.net/woshi1226a/article/details/86664159
https://blog.csdn.net/Deronn/article /details/106574498
https://blog.csdn.net/good_good_xiu/article/details/118567249