のブームで テクノロジーでは、IT担当者が複数のデータを同時に処理することは避けられず、データは時間とともに進化し続けます。また、データのすべての変更を追跡し、必要に応じて不要な変更を元に戻したり元に戻したりする準備をすることも不可欠です。
告白する必要があります。Gitでデータをバージョン管理することで、プロジェクト開発をより実験的に行うことができます。私が混乱した場合、gitには常に、プロジェクトのそのバージョンを元に戻したり、失敗する前の状態に戻したりする方法があることを知っています。各 レイヤーは、次の段階でデータを移動する前に、データの変更を確認、変更、修正できるように設計されています。したがって、このブログで取り上げられている間違いは次のとおりです。
- インデックスからファイル/ディレクトリをステージング解除する
- 最後にコミットされたメッセージを編集する
- 最後のコミットでいくつかの変更を忘れました
- ローカルの変更を破棄する
- ローカルリポジトリにコミットされた個人データ
- 最新のコミットを新しいコミットに置き換えました
- 間違ったデータをコミットしました
- 以前のプロジェクトの状態に戻ります
- 削除されたローカルブランチを回復する
- コミットで行われた変更を元に戻す
- 私のブランチに間違った名前を付けました
- リモートにプッシュする前に履歴ログを再配置したい
- 関係のない変更を1つのコミットにコミット
- すべてのブランチのすべてのコミットで作成者の電子メールを変更する
- 遺失物取扱所
- どのブランチにコミットIDがあるか忘れました
- 履歴からコミットを削除する
- 間違ったブランチをリモートにプッシュしました
インデックスからファイル/ディレクトリをステージング解除する
ファイルを追加または変更するときは、「git add」コマンドのデフォルトの動作を使用する傾向があります。これは、すべてのファイルとディレクトリをインデックスに追加することです。多くの場合、特定のファイルをコミットする前に、ステージングを解除するか、最後にもう一度変更する必要があると感じます。
構文： gitリセット
cのリンクリストプログラム
インデックス領域からファイルのステージングを解除すると、ローカルリポジトリにコミットする前に、データを再処理する別の機会が得られます。
最後にコミットされたメッセージを編集する
コマンド： git commit --amend
新しいコミットメッセージを作成せずに、最新のコミットメッセージを編集できます。コミットログを一覧表示するために、エイリアス「hist」を設定しました。
コマンド： git config --global alias.hist 'log --pretty = format： '％C（yellow）％h％Creset％ad | ％C（緑）％s％Creset％C（赤）％d％Creset％C（青）[％an] '-graph --decorate --date = short'x
すでにリモートリポジトリにプッシュされて他のユーザーと共有されているコミットメッセージを修正しないでください。修正すると、以前のコミット履歴が無効になり、それに基づく作業が影響を受ける可能性があります。
最後のコミットでいくつかの変更を忘れました
いくつかの変更を加えるのを忘れて、すでにスナップショットをコミットしたとします。また、間違いを強調するために別のコミットをしたくないとします。
コマンド： git commit --amend
最近のコミットオブジェクトのsha-1IDがどのように再作成および変更されたかを強調しました。私は、両方の変更を1つにブレンドする単一のコミットを行ったふりをしました。
ローカルの変更を破棄する
そこで、「README」ファイルを変更してステージングした場合を次に示します。次に、同じファイルを2回変更しましたが、2回目の変更は必要ないことに気付きました。
ここで、変更全体を手動で元に戻すのではなく、ステージングされたバージョンのファイルをプルするだけです。
構文：
gitcheckout-–ファイルのローカル変更
gitcheckout-–ディレクトリ内のすべてのファイルのローカル変更＆shy＆shy
コマンド： git checkout-README
そのため、ファイルへの最後の変更を破棄し、ステージングされたバージョンのファイルを受け入れました。次のコミットでは、ステージングされたバージョンのファイルだけがローカルリポジトリに格納されます。
ローカルリポジトリにコミットされた個人データ
ローカルリポジトリから特定のデータを削除したいのですが、ファイルは作業ディレクトリに残しておきます。
構文：
git reset --mixed HEAD〜
git reset --mixed
コマンド： git reset --mixed HEAD〜1
HEAD〜1は、現在のブランチHEADが指す最近のコミットの直前のコミットを示します。
現在のスナップショット内のファイルは、ローカルリポジトリとステージング領域の両方から削除されました。グローバル.gitignoreファイルに次のパターンを追加して、gitによる追跡から除外します。
vim〜 / .gitignore_global
＃パスワードファイル＃
*。パス
*。キー
* .passwd
これにより、パスワードファイルのスナップショットが含まれていたコミットが削除され、クリーンなステージング領域が得られます。私のファイルはまだ作業ディレクトリに存在しますが、ローカルリポジトリには存在しなくなり、リモートリポジトリにもプッシュされません。
あぶない： あなたがそれらを失った場合、gitはそれについて知らないのであなたのためにそれらを回復することはできません。
最新のコミットを新しいコミットに置き換えます
構文： git reset --soft [/ HEAD〜n>]
「–soft」オプションは、コミットされたファイルがまだインデックスにステージングされている間にローカルリポジトリから削除するだけで、レビュー後にそれらを再コミットできます。ローカルリポジトリから削除するスナップショットのsha-1です。ここで、nはHEADコミット前のコミット数です。
コマンド ：git reset --soft HEAD〜1
ファイルを変更して再度ステージングする
コマンド： git commit -m'index.htmlとstyle.cssの追加 '
コミット履歴は次のようになります。
間違ったデータをコミットしました
構文：
git reset --hard HEAD〜n–最新のコミットされたスナップショットの前にプロジェクトを「n」コミットにリセットします
git reset --hard–プロジェクトを指定されたコミットIDスナップショットにリセットします
コマンド： git reset --hard HEAD〜1
最新のコミットと破損したファイルは、ローカルリポジトリ、ステージング領域、および作業ディレクトリから削除されます。
あぶない： 作業ディレクトリ内のファイルが失われるため、これは危険なコマンドです。リモート共有リポジトリでは推奨されません。
以前のプロジェクトの状態に戻ります
あなたは時間の歴史の中であなたのプロジェクトの古い状態にぶつかることができます。最新バージョンを台無しにしたり、古いコードの拡張が必要な場合は、現在の作業を妨げないように、その古いプロジェクトスナップショットから別のブランチを作成することをお勧めします。方法を見てみましょう：
a。プロジェクト履歴をリストし、古いコミットID、コマンドを決定します。歴史に行く b。コミットIDから別のブランチを作成します。
git checkout -b old-state e7aa9a5
c。コードの作業を続け、後で「マスター」ブランチとマージ/リベースします。
削除されたローカルブランチを回復する
失われた作業を参照ブランチで再生成することができます。たとえば、メインブランチとマージせずにブランチ「old_code」を削除し、作業を失ったとします。いいえ、ブランチをリモートリポジトリにプッシュしませんでした。 gitは追跡し、各参照で行われたすべての変更のジャーナルエントリを保持します。私のものを見てみましょう。reflogに行く
したがって、HEAD @ {2}は、「old_code」ブランチに移動したときのポインタです。それを回復しましょう。
構文：git checkout -b
コマンド：git checkout -b old_code HEAD @ {2}
これで、作成時の最新の作業で「old_code」ブランチにいる必要があります。さらに、HEAD @ {1}の「reflog」ポインタは「old_code」ブランチで行われた最近のコミットでした。この一意のファイルを復元するにはcommitは、次のようにコマンドを実行するだけです。git reset --hard HEAD @ {1}。これにより、変更されたファイルが作業ディレクトリに復元されます。
このコマンドがどのように機能し、「reflog」エントリをどのように管理できるかを詳細に知りたい場合は、以前の投稿を読んでください。削除されたブランチをgitreflogから復元する。
コミットで行われた変更を元に戻す
行く元に戻す以前のコミットの効果を逆転させるために、いくつかの新しいコミットを記録するために使用されます。
構文： git revert
コミットログから、強調表示されたコミットIDで行われた変更を元に戻したいと思います。
コマンド： git revert 827bc0d
共有コミットを「–hard」リセットせず、代わりに「git revert」して履歴を保持することをお勧めします。これにより、すべてのユーザーが履歴ログを追跡して、誰が何を元に戻したかを簡単に見つけることができます。なぜ？
HEAD〜3やHEAD〜4などのように、コミットIDを指定する代わりに、HEADポインターに関するコミットを参照するのと同じロジックを使用できます。
私のブランチに間違った名前を付けました
ローカルブランチ名の名前を変更できます。何度も発生するため、すべての作業をある場所から別の場所に移行するという苦痛を経験することなく、作業中の問題に基づいてブランチの名前を変更したい場合があります。たとえば、同じブランチまたは別のブランチにいても、次のように目的のブランチの名前を変更できます。
構文： gitブランチ-m
コマンド： git branch -m old_code old_＃4920
不思議に思うかもしれませんが、gitはこの名前の変更を追跡していますか？はい、それはあなたの「reflog」エントリを参照します、ここに私のものがあります：
ブランチの名前を変更しても、そのリモート追跡ブランチには影響しません。リモートリポジトリのブランチを置き換える方法をリモートセクションで確認します
インスタンスJavaとは何ですか
リモートにプッシュする前に履歴ログを再配置する
特定のコミットを他のコミットよりも早く行い、一部のコミットをまったく行わなかったとしたらどうでしょうか。古いコミットをインタラクティブに再配置および編集して、コードを効果的に修正または拡張します
構文： git rebase -i
コマンド： git rebase -i fb0a90e–コミットIDfb0a90eの後に行われたコミットのリベースを開始します
再訪問 gitリベース 「–interactiveまたは-i」リベースが通常のリベースとどのように異なるかを理解するためのドキュメント。
関係のない変更を1つのコミットにコミット
この場合、古い埋め込みコミットを複数の論理コミットに分割する必要があります。
構文： git rebase -i
コマンド： git rebase -i fb0a90e
リベースエディタで、e7aa9a5コミットIDを選択し、「pick」ではなく「edit」に変更する必要があります。
これで、プロジェクトのバージョンのコミットID-e7aa9a5になります。まず、コミット履歴とステージング領域を前のコミットにリセットします-コマンド：git reset HEAD〜1
次に、ファイルを個別に編集+ステージング+コミットします
コマンド：
git add code && git commit -m '初期コードの追加'
git add newcode && git commit -m '新しいコードの追加'
第三に、リベースを続行して終了します。
コマンド ：git rebase --continue
第4に、追加のコミットで履歴を表示します。
コマンド： 歴史に行く
すべてのブランチのすべてのコミットで作成者の電子メールを変更する
私は長い間、プロジェクトファイルをgitでバージョン管理してコミットしてきましたが、リモートリポジトリに公開されているコミット履歴ログでメールIDが危険にさらされていることに気付くことはありませんでした。さて、これは、「。gitconfig」ファイルで最初に構成をセットアップしたときに誰にでも起こる可能性があります。 リライト コミットオブジェクトを作成するときに提供する環境変数。
まず、のリストを取得します メールID 私が変更したいものを決定するには：
コマンド： git log --all --pretty = format： '％an％d'–これは作成者名（refname / branch-name）を出力します
第二に、私は通り抜けます 各ブランチのすべてのコミット コミットオブジェクトを新しいメールIDで書き直します
コマンド：
git filter-branch --env-filter '
if ['$ GIT_AUTHOR_NAME' = 'divya']
その後
GIT_AUTHOR_EMAIL ='divya@github.com '
あります
' - - すべて
遺失物取扱所
特定のファイルを紛失し、その名前を覚えていないが、ファイル内の特定の単語を思い出すことができたとします。この場合、次の手順に従うことができます-
ステップ1： 検索されたパターンでファイルスナップショットを含むすべてのコミットを一覧表示します
コマンド ：git rev-list --all | xargs git grep -i 'タイムスタンプ'
ステップ2 ：この強調表示されたcommit-idから「lost-found」の新しいブランチを作成します
構文： git checkout -b lost-found d8c6a76a6dcb1fc6e8c3f6b097e1bd07e7cd328f
どのブランチにコミットIDがあるか忘れました
バグのあるコミットIDを検出した後、すべてを修正できるように、このコミットが設定されているすべてのブランチを知りたい場合があります。大規模な複数支店のプロジェクトでは、各支店の履歴を確認することはあまり実用的ではありません。
ナビゲーション構築アプリケーションで行われた不正なコミットがコードを壊したことがあります。そのとき、 不正なコミットIDを検出するための「gitbisect」コマンド 続いてコマンド：gitブランチ-含むその悪いコミットでブランチをリストします。
これで、まだコミットが正しくないすべてのブランチがわかったので、このチェンジセットを元に戻すかリセットすることができます。
履歴からコミットを削除する
時々、私はただ歴史からコミットを一掃し、それの痕跡を残さない必要を感じる。共有ブランチでこのスタントを試すことはお勧めしませんが、ローカルブランチでのみ試してください。
構文： git rebase -i
コマンド ：git rebase -i 93859d8
リベースエディタで->強調表示されたコミットIDの「edit」を「drop」に置き換えます：69f4813
場合によっては、この書き直しによって競合が発生する可能性があります。競合を解決してから、さらに先に進む必要があります。
警告 ：これは履歴を書き換えてデータを失う可能性があるため、危険なコマンドです。このようなブランチはリモートカウンターパートとは異なり、でプッシュする必要があります。 - 力または--force-with-leaseオプション。
間違ったブランチをリモートにプッシュしました
さて、これが私がしたいことです-私は削除したい リモートブランチ また、私の地元の支店からの追跡を停止します。」git push‘コマンドを-削除オプションはリモートブランチを削除しますそれで、これは私がクローンプロジェクトのローカルコピーを取得する方法です–
git clone https://github.com/greets/myProj.git
cd myProj
リモートブランチが削除されると、共有リポジトリ上の他のブランチは、リモート参照を更新および更新する必要があります。 - プルーン欠落しているオブジェクト参照を削除するオプション：git fetch --prune -v origin
この投稿では、gitが修正に役立つ一般的な間違いや変更のいくつかについて説明しました。すべてのコードは一意であり、その方法で開発されているため、問題にアプローチして修正するさまざまな方法もあります。あなたはいつでも公式を参照することができます gitドキュメント さまざまなgitコマンドがソースコードを保護する方法と、コマンドを可能な限り最善の方法で利用する方法を理解する。
一般的なGitの間違いを理解したので、これをチェックしてください 25万人以上の満足した学習者のネットワークを持つ信頼できるオンライン学習会社であるEdurekaが世界中に広がっています。 Edureka DevOps認定トレーニングコースは、学習者がDevOpsとは何かを理解し、SDLCの複数のステップを自動化するためのPuppet、Jenkins、Nagios、Ansible、Chef、Saltstack、GITなどのさまざまなDevOpsプロセスとツールの専門知識を習得するのに役立ちます。
質問がありますか？この「よくあるGitの間違い」のコメントセクションにその旨を記載してください。折り返しご連絡いたします。