Git騒乱操作

6842 ワード
git 学習ノート
公式ドキュメントには、取り消し操作に関する内容があります.https://git-scm.com/book/zh/v2/Git-%E5%9F%BA%E7%A1%80-%E 6%92%A 4%E 6%B 6%88%E 6%93%8 D%E 4%BD%9 Cは、公式の説明を参照してください.ここでは,実際に起こりやすい問題と結びつけて,解決策を提示する.
前回のコミットの変更git addの後、git commitが実行されてコミットされる.git commitを直接実行すると、テキストエディタがコミットしたメッセージを変更するポップアップが表示されます.-mパラメータgit commit -m "message"を使用して、コマンドラインに直接送信メッセージを提供することができる.問題は、スペルエラーなどのエラーメッセージを送信しました.前回コミットしたメッセージを変更する必要があります.最後にコミットされたメッセージは、次のコマンドで変更できます.
$ git commit --amend
$ git commit --amend -m "message2"

問題はコミットが完了した後、前回のコミットに問題があることに気づきました.例えば、書類の提出を漏らしたり、ある書類をもう一度修正したりします.もちろんもう1つのバージョンを提出してもいいですが、--amendを使用すると、前回の提出内容に新しい内容を提出することができます.
$ git add .
$ git commit --amend

問題コミットがリモート・ウェアハウスにアップロードされている場合.上記の変更により、ローカルのバージョンとリモート・ウェアハウスが一致しないため、リモート・ウェアハウスに直接コミットできません.強制的にコミットする必要があります.
$ git push --force

ここのやり方は提出に問題があるので、前回の提出をなんとか修正します.もう一つの考え方は、前回の提出を削除し、正しい提出を再び提出することです.次に、リモートの最後のコミットを削除する方法について説明します.
以前にコミットされたバージョンが既に1台のホストにダウンロードされている場合、このマシンのローカルブランチとリモートブランチが一致しません.次のコマンドは、ローカルのブランチをリモートのブランチに置き換えることです.
$ git fetch --all                            #     
$ git reset --hard origin/master  # master         
$ git pull                                     #

これがローカル修正を放棄する操作であり,以下単独でも述べる.
ブランチ名の変更
ブランチ使用コマンドの作成:
$ git branch branch_name

ここではブランチを作成するだけで、現在のブランチは切り替えられません.ブランチを切り替えるにはcheckoutコマンドを使用します.
$ git checkout branch_name

新しいブランチを開き、新しいブランチを変更する場合は、上の2つのコマンドを使用して解決することもできます.
$ git checkout -b branch_name

問題のブランチ名が間違っています.ブランチ名を変更します.-mパラメータを使用してブランチ名を変更できます.
$ git branch -m branch_name new_branch_name

問題のあるブランチ名がリモートサーバにプッシュされました.この場合、遠位端のエラーのブランチを削除し、新しいブランチをアップロードするしかありません.
$ git push origin --delete branch_name
$ git push origin new_branch_name

直接メインブランチで修正しました
まだcommitがない場合は、ブランチを直接切り替えて、修正をコミットすればいいです.問題は、次の3つのコマンドを使用して、メインブランチに一時的な変更をコミットしました.
$ git branch branch_name
$ git reset HEAD~ --hard
$ git checkout branch_name

最初のコマンドは、ブランチを作成した後、プライマリブランチと新しいブランチが現在のバージョンにあります.現在のブランチはプライマリブランチです.2番目のコマンドでは、HEAD~はHEADを1回ロールバックしますが、現在のブランチがメインブランチであるため、メインブランチは1つのバージョンをロールバックし、新しいブランチはまだ最新のバージョンにあります.HEAD~の後ろの~号は、HEADを前に1つのバージョンを戻すことを示す.~がなければ、HEADつまり現在のバージョンに戻ります(commitを過ぎたばかりなので、何も起こらないはずです).hardパラメータも必要です.このパラメータがない場合、バージョンはロールバックされますが、ローカルの新しいファイルの一部は保持されます.最初のコマンドの後、これらの変更は新しいブランチにすでに存在するため、新しいファイルは保持する必要はありません.これらのファイルが残っている場合、3番目のコマンドを実行すると、ローカルにファイルがあるため、切り替えを行うと、新しいブランチのファイルとローカルのファイルの同名が衝突します.3番目のコマンドは、新しいブランチに切り替え、新しいブランチで作業を継続します.
エラーファイルが追加されました
ファイルを追加するコマンドはgit addで、すべてのファイルをポイントでコミットできます.
$ git add .

addが間違っていることが判明した場合は、git resetコマンドを使用します.
$ git reset
$ git reset filename

パラメータなしですべての追加を撤回し、ファイル名を付けると指定したファイルのみを撤回します.
問題はもうcommitです.
$ git reset --soft HEAD~

これでcommit前、add後の状態に戻ります.--softパラメータを持たない場合は、addより前の状態です.そしてもう一度提出し直します.
小結git resetは2回git resetに使用されています.まとめてみます.
  • HEADは現在の位置
    • を示す.
  • HEAD~は、1つのバージョンをロールバックすることを示し、ルート数が可能で、デフォルトは1です.
  • HEAD~2は2バージョンのロールバックを示す.
  • --hard削除ファイル
  • --soft保存ファイルgit add以降の状態
  • のデフォルトも保存ファイルでありgit add以前の状態です.

    • ローカル変更を破棄
    ローカル変更を破棄し、サーバーコードを使用してローカルコンテンツを上書きします.
    $ git fetch --all
$ git reset --hard origin/master 
$ git pull

    masterブランチを使用してローカルを上書きします.他のブランチを使用すると、2番目のコマンドのパラメータが変更されます.git fetch:マージやrebaseを試みずに、リモートから最新のものをダウンロードします.git reset:取得したコンテンツにプライマリブランチをリセットします.--hardパラメータは、すべてのファイルgit pullを変更します.上の2ステップで完了します.このステップは必要ありませんが、検証にも使用できます.
    さらに安全な方法は、リセットする前に、現在の変更を保存するためにブランチを再構築することです.
    $ git checkout master
$ git branch master-bak
$ git fetch --all
$ git reset --hard origin/master

    古いコミットはすべてmasterbakに保存されます.ただし、stagedであってもコミットされていない変更は失われます.必要なものを保存して提出してください.
    究極の大技
    コマンドgit reflogを使用して、すべてのことのリストを表示します.そして1つの時点を選択して、その時の状態に切り替えることができます.簡単に使うことをお勧めしません.切り替え時にコマンドを使用:
    $ git reset HEAD@{index}

    {index}は、git reflogコマンド出力の各行の一番左のid番号の列に置き換えられます.
    github操作
    修正をリモートウェアハウスにアップロードした場合は、リモートウェアハウスの提出も修正する必要があります.よくある問題は、パスワードなどの機密情報を送信することです.権威のある指導が必要な場合は、次はgithubの公式helpドキュメントです.Removing sensitive data from a repository:https://help.github.com/en/articles/removing-sensitive-data-from-a-repository
    次に、他の状況の救済方法を展開します.
    リモートウェアハウスを完全に上書き
    この方法は簡単で乱暴だが、リスクも大きい.やる前に遠隔倉庫をcloneしてもいいです.
    $ git clone

    ローカル・ウェアハウスに問題がない場合は、リモート・ウェアハウスを強制的に完全に上書きできます.
    $ git push origin --force --all

    パラメータ--forceは強制プッシュです.パラメータ--allはすべてのブランチを指します.このパラメータは状況に応じて使用できますが、追加しないと1つのブランチだけを上書きし、1つのブランチだけを上書きして次のセクションの内容を見ることができます.
    ブランチを上書き
    ここでは、メインブランチを例に、マスターブランチを削除して新しいマスターブランチをコミットします.ここの方法は少し穏やかです.リモートのブランチを削除してから、ローカルのブランチをリモートにプッシュします.相当して遠隔倉考をカバーしますが、カバーの範囲は1つの分岐にすぎません.また.万一に備えて、操作前にバックアップの作業も行いました.また、このバックアップのブランチもリモート・ウェアハウスにプッシュできます.万一に備えてバックアップ・ブランチを作成します.
    $ git branch old_master
$ git push origin old_master:old_master

    作成後、このブランチもリモート・ウェアハウスにプッシュできます.最後にこのブランチを削除することもできます.
    リモートのmasterブランチを削除するには:
    $ git push origin :master

    リモートブランチを削除するコマンドについて、ローカルブランチをリモートにプッシュする完全なコマンドは次のとおりです.
    $ git push [   ] [    ]:[    ]

    一般的にコミットする場合、後のリモートブランチ名は省略されます.時分割枝を削除すると、ローカルブランチ名が空白になり、コロンとリモートブランチ名のみが書き込まれます.空のローカルブランチをリモートブランチにプッシュすることは、リモートブランチを削除することと理解できます.ブランチを削除するには-d, --deleteパラメータを使用します.次の2つのコマンドは同じ効果です.
    $ git push origin --delete 
$ git push origin :

    新しいマスターブランチをローカルでマスターブランチの変更を完了してから、リモートにコミットします.
    $ git push origin master

    ここには、バックアップとして使用するブランチがリモート・ウェアハウスに残っています.必要に応じて削除します.
    リモート最後のコミットの削除
    誤りを提出した後の救済について、上はもう一つの考えを述べた.ここは別の考え方です.
    基本的な操作は、まずローカルでバージョンをロールバックし、値リモート・ウェアハウスを強制的にプッシュします.
    $ git reset HEAD~
$ git push --force

    上のresetにはパラメータが付いていません.後退した後も、変更したファイルはローカルに残っています.git add前の状態です.上記2つのコマンドを実行した後、リモートウェアハウスの最後のコミットはなくなりました.ローカルの修正はまだあります.このとき、以前に提出した問題点を修正し、通常の提出操作を実行します.
    $ git add .
$ git commit -m "message"
$ git push

    一時保存機能を加えた操作用git stashの一時保存機能:
    $ git reset commitId
$ git stash
$ git push --force
$ git stash pop
$ git add . 
$ git commit -m "massage" 
$ git push

    ここではstashとpopの間に修正された操作がないため、一時保存の効果を使うのは少し余計なようです.これはpopの前に他の計画外の操作がある可能性があることを防止するためだろう.
    leetcode 180週目
    Qtcreatorコンパイルのプログラムに管理者権限を持たせる