ほとんどの開発者は、いくつかの Git コマンドがほとんど不公平だと感じ始める段階に達します。これらは何時間にもわたる混乱を数分で解決し、実際に動作しているのを初めて見たときは不可能に思えるレベルの制御を提供します。これらのコマンドを私自身が紹介すると、経験豊富な Git ユーザーがこのツールを威圧的であると同時に不思議なほど安心できると評する理由が説明されました。何かを壊し、パニックが起きるのを感じ、短い一連のコマンドを実行すると、混乱全体がまるで存在しなかったかのように解消されます。
以下のコマンドは、私が個人プロジェクト、仕事、オープンソースへの貢献のために利用したものです。これらは習得が簡単で、驚くほど強力で、丸一日の労力を節約できます。同じ力は危険性も伴うため、いつ使用するべきか、いつ退くべきかを理解するのに役立ちます。
以下は、本当に不正行為であると思われるコマンドと、それが良いことよりも害をもたらす瞬間です。
git add -p: 良い部分のみをステージングします
他の人の Git 履歴を調べてみると、試行錯誤を繰り返しながらツールを学習した開発者を見つけることができます。彼らのコミットには、無関係な変更、中途半端な作業、誤って紛れ込んだデバッグ出力が混在しています (私も認めたくないほど何度も同じことをしてきました)。彼らが本当に必要としているのは、有用な編集と偶発的な編集を区別する方法であり、Git にはまさにそのために設計された機能がすでに含まれています。
の git add -p は、変更したファイルをハンクと呼ばれる小さなセクションに分割し、それぞれをステージングするかどうかを尋ねます。これにより、変更内容が単純なチェックリストに変わり、現在のコミットに属する部分を含めることができ、実験的な部分や面倒な部分は後で残しておくことができます。実際には、何も直接編集せずに、その場で作業内容を書き直すことができるように感じられます。クリーンコミットは（最終的には）自然な習慣となり、あなたの履歴を読む人は誰でもその恩恵を受けます。その中には、ある日、ルーチンのスタイル修正であるはずのものになぜ野良変数を紛れ込ませたのか疑問に思う未来のあなたも含まれます。
使用しない場合
行駆動の変更が意味をなさない巨大な自動生成ファイルやコード ベースを操作している場合、インタラクティブなステージングは遅くて煩わしいエクスペリエンスになってしまいます。ファイル全体をステージングした方がクリーンなだけでなく、より正確な場合もあります。
git commit — amend: 誰にも見られずに履歴を書き換えます
急いで git commit を実行すると、通常は手遅れになってすぐに間違いに気づきます。時々、ファイルのステージングを忘れたり、単純なタイプミスを見逃していたりすることがあります。些細なことのために別のコミットを作成するのではなく、単一のコミットで前のコミットを修正できます。 git commit –amend このコマンドを使用すると、段階的な変更が更新され、メッセージを 1 ステップで書き換えることができます。
これを使用すると、制御されたタイムトラベルのような気分になります。古いコミットは消え、修正されたバージョンが代わりに配置され、履歴はエラーが最初から存在しなかったことを示しています。レビュー担当者は一連の小さな修正コミットを避けるため、最初の試行で一貫して完璧な作業を提供できるという心地よい錯覚を覚えます。
使用しない場合
誰もが履歴の書き換えに満足していると完全に確信できない限り、共有リポジトリにすでにプッシュされているコミットを修正しないでください。パブリックコミットを変更すると、他のコントリビューターは分岐したブランチや混乱を招くマージに対処する必要があります。
git reflog: 失われたコミットを回復する
Git ではデータがほとんど失われないと人々が言うとき、それは reflog のことを指します。ブランチが通過するすべての変更を記録します。リベース中にブランチをリセットしたり、誤ってブランチを削除したり、コミットを過ぎたりした場合、reflog には各ステップが順番に保存されます。この記録により、アクションを追跡し、失われたと思われる作業を復元することができます。
初めて git reflog を使用したとき、数時間の作業を取り除くリセットを実行したばかりでした。変更が失われたのだと思いました。 reflog を見ると、必要な正確なコミットが示されており、それを確認するとすべてが復元されました。状況はすぐに解決し、このインシデント全体によって、Git でのリカバリについての私の考え方が変わりました。
使用しない場合
特にシャロー クローンやガベージ コレクションが積極的に実行された場合、Reflog エントリは最終的に期限切れになります。これは適切なバックアップに代わるものではないため、長期的なリカバリに依存しないでください。
git Cherry-pick: 1 つのコミットを取得し、残りは無視します
チェリーピッキングを使用すると、履歴の任意の時点から 1 つのコミットを取得して、それを現在のブランチに適用できます。コミットを含むブランチの残りの部分は取り込まれません。機能ブランチから修正が 1 つだけ必要な場合は、変更セット全体をマージせずにそれを適用できます。
これは、運用上の問題が発生し、その修正が開発ブランチにすでに存在していることを覚えている場合に役立ちます。まだ進行中の大量の作業をマージする代わりに、問題を解決するコミットのみを適用できます。安定したブランチはフォーカスされたままとなり、レビューの準備ができていないマージを強制することを回避できます。
使用しない場合
チェリーピッキングは新しいコミット ハッシュを作成します。長時間実行されているブランチ間でチェリーピッキングを頻繁に行うと (軽視されているのはご存知ですか?)、重複したコミットが作成され、後にマージ競合や履歴の混乱を引き起こす可能性があります。
おそらく聞いたことのない 4 つの高度な git コマンド
Git ゲームを次のレベルに引き上げましょう。
gitリセット – ハード: 核の取り消し
ほとんどの人はこのコマンドを避けますが、このコマンドはステージングされていない変更をすべて削除し、作業ディレクトリをリセットし、ブランチ ポインタを選択したコミットに移動するため、その懸念は当然です。これは、作業の現在の状態を保持する価値がなくなり、できるだけ早くクリーンなディレクトリに戻りたい場合に便利です。
実験に何日も費やすと、作業ツリーが放棄された試行や部分的な編集でいっぱいになることがよくあります (それを手動でクリーンアップするのは非常に時間がかかります)。使用後 git add -p コミットに集中し続けるために、このコマンドを使用すると、残りの変更を 1 つのステップで消去できます。その結果、以前の作業中に蓄積されたノイズが一切なく、新たなスタートが可能になります。
使用しない場合
コミットされていない重要な作業がある場合は、このコマンドを決して使用しないでください。作業内容を保持しつつブランチから削除したい場合は、次を使用します。 git スタッシュ その代わり。ハードリセットは、現在の状態を躊躇なく消去したい場合にのみ使用できます。
git clean -fd: コミットされていないものをすべて削除します
プロジェクト ディレクトリには、ビルド アーティファクト、一時ログ、エディタのバックアップ、コンパイルされたバイナリなどの残りのファイルが収集される場合があります。 Git clean はそれらをすべて一度に削除します。追跡されていないファイルまたはディレクトリが削除されるため、実際のバージョン管理状態と一致するクリーンなリポジトリに戻ることができます。
ビルド ファイルのレイヤーを生成する大規模なプロジェクトまたはフレームワークを操作する場合、ワークスペースをクリーンアップすると、一見無関係に見えるエラーが修正されることがあります。これは、実際に変更したファイルを危険にさらさずにガベージを削除するために私が知っている中で最も迅速な方法です。
使用しない場合
意図的にバージョン管理から外した構成ファイルなど、追跡されていない重要なファイル (私はそうしました) が含まれるディレクトリ内で実行しないように注意してください。早速 git clean -n 続行する前に、削除されるものが表示されます。
git rerere: 記録された解像度を再利用する
初めてレレレのことを聞いたとき、冗談だと思いました。名前は再利用記録解像度の略であり、機能であると同時に git コマンドでもあります。 Git は特定の競合をどのように解決したかを記憶し、次回同じ競合が発生したときに同じ解決策を自動的に適用します。頻繁にリベースする長時間実行ブランチを扱う場合、このツールを使用すると時間を大幅に節約できます。
最も良い点は、rerere がバックグラウンドで静かに動作することです。競合を一度解決すると、Git がパターンを記録します。後で再度マージまたはリベースを行うと、Git は即座に修正を再利用します。それは、合体戦闘中にメモを取り、同じ敵が戻ってきたときに介入してくれる小さなアシスタントがいるようなものです。リポジトリで使用するには、次のコマンドを使用して有効にします。
git config rerere.enabled true
git config rerere.autoupdate true
使用しない場合
競合解決が頻繁に変更される場合、またはコンテキストに依存する場合、rerere は意味をなさない解決を適用し、このリストの他のコマンドと同様に、使用前に確認して問題を混乱させる可能性があります。
このオープンソース Linux アプリのおかげで、git コマンドを使わなくなりました
これはおそらく私が使った中で最高の TUI で、見た目も素晴らしいです。
Git は、歴史を自分に起こったこととしてではなく、自分で形作ることができるものとして扱うことを推奨します。他のバージョン管理システムも基本的な元に戻す機能を提供しますが、Git ではブランチを完全に再構築し、失われた作業を回復し、変更を 1 行ずつプレビューし、必要に応じてタイム トラベルを行うツールが提供されます。ただし、強力な機能には大きな混乱が伴います (現時点で Git のマニュアル ページは 1514 行です)。多くの開発者が本番サーバーよりも Git を恐れて育つ理由はこのためです。
秘訣は、これらのコマンドを常に使用するのではなく、最小限のリスクで最大の影響を与えるタイミングを知ることです。以前は苦痛だった状況で優位に立つので、不正行為をしているように感じます。修正方法は必ずしも明らかではありませんが、コマンドを理解すると、自信はすぐに高まります。