著者：lzaneli、TencentTEGフロントエンド開発エンジニア
この記事はこのシリーズの最後の記事です。前回の記事では主に基本原則について説明しました（上のアルバムを参照）。原則を理解した上で、開発効率の向上を願って、実践的なスキルを皆さんに紹介します。
この記事は実際的なテクニックを列挙することを目的としているため、記事の構造は少し乱雑に見え、前の2つの記事のように全員が順番に読む必要はありません。各ポイントは互いに独立しており、誰もが自分のニーズに応じて学ぶことができます。
この記事では、画面記録の操作方法を使って例を紹介します。この方法で、コマンドの使い方をより直感的に理解できるようになることを願っています。
複数のコミットを1つに圧縮します
⚠️ここで特に注意する必要があるのは、リベースすると新しいコミットノードが生成されるため、複数の人が共有するリモートブランチをリベースしないように注意してください。
rebase -iこれは非常に実用的で広く使用されているツールです。皆さんに使い方を学んでいただきたいと思います。また、コミット情報の変更、特定のコミットの破棄、コミットの並べ替えなどにも使用できます。具体的なコマンドは以下のとおりです。操作モードはアニメーションと同じで、すべてvimで編集されます。ここで拡大するのではなく、興味のある学生は自分でそれを行うことができます。
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# x, exec <command> = run command (the rest of the line) using shell
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
# . create a merge commit using the original merge commit's
# . message (or the oneline, if no original merge commit was
# . specified). Use -c <commit> to reword the commit message.
また、最新のコミットのいくつかをマージする場合は、を使用git reset --soft HEAD~3 && git commit -m 'xxx'して達成できます。この問題のある学生については、Gitの内部原則によって強調されている視覚化方法を参照できます。
欠落しているコミットノードまたはブランチを取得します
前のステップでリベースした後、期待を満たしていないことがわかりました。どのように回復しますか？誤ってブランチを削除しましたが、どうすれば元に戻すことができますか？
「このスキルを学ぶと、同僚からミルクティーを飲むように言われ、女の子を収穫できるかもしれません。」-前のコースのクラスメート
主なアイデアは、返されるコミットオブジェクトのハッシュ値を見つけて、git resetリカバリを実行することです。
Gitの登場は、操作ができるだけ失われないようにすることであることがわかっています。Gitの内部原則では、gitオブジェクトが作成されると、対応するハッシュ値が見つかった場合にそれを取得できる限り、変更することはできないと述べています。 。しかし、refはどうですか？また、Gitの内部原則で、これは可変ポインターであると述べました。たとえば、マスターでコミットを送信すると、現在のマスターの参照は新しいコミットオブジェクトのハッシュ値を指します。reflogは、これらの履歴レコードへの変数ポインターであり、log refとして理解できます。また、バージョンコントロールバージョンコントロールとして理解することもできます。
清潔な作業スペースを確保する
アイデアを試したり、コードについて友人と話したりするときは、コードを自由に変更できます。また、通常の開発に戻るときは、クリーンな作業ディレクトリが必要です。つまり、現在の作業ディレクトリがGitの最後のコミットファイルと一致していることを確認する必要があります。私たちは何ができる？
これらのファイルが不要であることが確実でない限り、ファイルを失う操作を最小限に抑えるようにしてください。
最後のコミットを変更する
コミット後、削除するのを忘れた一時的なログがあることがわかりましたか？一部のファイルを追加するのを忘れましたか？コミットメッセージにタイプミスが表示されますか？
これを使用してgit reset HEAD~、必要な変更を実行してからコミットすることもできます。効果は、上記のコマンドと同じです。
ファイルの部分的な変更を送信する
Gitインタラクティブ追加にはさらに多くの機能があります。時間があれば試してみることをお勧めします。
複数の人が共有するリモートブランチを変更することは禁止されています
リモートブランチが複数のユーザーによって共有されている場合は、このブランチの既存のコミットオブジェクトを変更するresetおよびrebaseコマンドを実行しないでください。
具体的な説明については、この記事のリベースと説明されているゴールデンルールを参照してください。
合併を取り消す
ローカルブランチの場合は、それが必要git reset --hard <合并前的SHA1>です。
このブランチがリモートエンドにプッシュされた場合、たとえばマスターにマージされた場合、オンラインで投稿されたときにロールバックする必要があるバグがあることがわかります。このとき、他の人がブランチを使用している可能性があります。「複数の人が共有するリモートブランチの変更禁止」によるとgit revert -m 1 <合并的SHA1>、下図のE 'のような復帰ノードを実行して追加する必要があります。
ただし、元の機能ブランチで開発を続行しないように注意してください。代わりに、元のブランチを削除し、バグ修正のためにE 'ノードから新しいブランチを引き出します。
元の機能ブランチで開発を続ける場合は、マスターにマージするときにE 'ノードを元に戻してE' 'に変換するために元に戻す操作を実行する必要があります（以下を参照）。そうしないと、ファイルが失われたり、その他の問題が発生しやすくなります。特定の理由の分析は、ブランチマージの要約を参照します。
履歴全体からファイルを削除します
コードはオープンソースになりますが、キーファイルまたはイントラネットIPが含まれています。どうすればよいですか？
git filter-branch --tree-filter 'rm -f passwords.txt' HEAD
filter-branchコマンドを使用できます。その実装原則は、各コミットをチェックアウトし、上記のように指定したコマンドを実行してから、rm -f passwords.txt再度コミットすることです。
⚠️この操作はリスクの高い操作であり、履歴変更レコードチェーンを変更し、新しいコミットオブジェクトを生成します。したがって、実行前にウェアハウス内のすべての開発者に通知してください。実行後、すべての開発者は新しいブランチから開発を続行し、以前のすべてのブランチを破棄します。
その他の便利なコマンド
以下のコマンドもより実用的なコマンドであり、興味のある学生は自分で学ぶことができます。
git bisectバイナリ検索ノードの変更の問題が発生します。たとえば、現在のテスト中のアドバンスに合格しなかったが、テストHEAD〜10（10フロントサブミッション）がgit bisect完了した場合、問題のポイントを変更するためにナビゲートするために使用できます。。git blameコードの行を最後に変更したのは誰かを確認します。git show-branch複数のブランチ間の関係を視覚的に示します。git subtree倉庫を分割またはマージします。
読んでから何か見つけていただければ幸いです。興味のある学生は、同じシリーズの他の記事を読むことができます。
参照
书帳JonLoeliger 、Matthew McCullough-Gitによるバージョンコントロール、第2版-O'Reilly Media（2012）