13 の実践的な Git のヒント

Git の 13 周年を記念して、Git エクスペリエンスをより便利で強力なものにするための 13 のヒントとコツを紹介します。見落としているかもしれないいくつかの基本から始めて、実際のパワー ユーザー向けのヒントにまで広げてください。

1. ~/.gitconfig ファイル

初めて git コマンドを使用してリポジトリへの変更をコミットしようとすると、次のようなウェルカム メッセージが表示される場合があります:

リーリー

これらのコマンドが、Git がグローバル構成オプションを保存する場所である ~/.gitconfig の内容を変更していることに気づいていないかもしれません。 ~/.gitconfig ファイルを使用すると、エイリアスの定義、特定のコマンド オプションの永続的なオン (またはオフ)、Git の動作方法の変更 (たとえば、どの diff アルゴリズム git diff が使用するか、どの種類のタイプであるかなど) を含む多くのことを行うことができます。 diff はデフォルトのマージ戦略で使用されます)。リポジトリへのパスに基づいて、条件付きで他の構成ファイルを含めることもできます。すべての詳細については、man git-config を参照してください。

2. ウェアハウス内の .git/config ファイル

前のヒントで、git config コマンドの --global フラグが何をするのか疑問に思ったかもしれません。これは、~/.gitconfig 内の「グローバル」構成を更新するように Git に指示します。もちろん、グローバル設定があるということは、ローカル設定があることも意味します。 --global フラグを省略すると、git config は代わりに .git/config に保存されているリポジトリ固有の設定を更新します。

.git/config ファイルに設定されたオプションは、~/.gitconfig ファイル内のすべての設定をオーバーライドします。したがって、たとえば、特定のリポジトリに別の電子メール アドレスを使用する必要がある場合は、 git config user.email "only_you@example.com" を実行できます。そのリポジトリ内のコミットでは、個別に構成された電子メール アドレスが使用されます。これは、オープン ソース プロジェクトに取り組んでおり、仕事用電子メールをメインの Git 構成として使用しながら、プロジェクトに独自の電子メール アドレスを表示させたい場合に便利です。

~/.gitconfig で設定できるものはほとんどすべて、.git/config で設定して特定のリポジトリに適用することもできます。以下のヒントで、 ~/.gitconfig に何かを追加することに言及したとき、特定のリポジトリの .git/config に追加してそのオプションを設定することもできることを覚えておいてください。

3. エイリアス

エイリアシングは、~/.gitconfig で実行できるもう 1 つのことです。これはコマンドライン上のシェルのように機能します。通常は特定のオプションまたはフラグのセットを使用して、1 つ以上の他のコマンドを呼び出すことができる新しいコマンド名を設定します。これらは、頻繁に使用する長くて複雑なコマンドに最適です。

git config コマンドを使用してエイリアスを定義できます。たとえば、 git config --global --add alias.st status を実行すると、git st を実行すると git status を実行するのと同じことが行われます。しかし、エイリアスを定義するときに気づきました。通常は、~/.gitconfig ファイルを直接編集する方が簡単です。

この方法の使用を選択した場合、~/.gitconfig ファイルが INI ファイルであることがわかります。 INI は、特定の段落を含むキーと値のファイル形式です。エイリアスを追加する場合は、[エイリアス]段落を変更します。たとえば、上記と同じ git st エイリアスを定義する場合、次のコードをファイルに追加します:

リーリー

(既に [alias] 段落がある場合は、既存のセクションに 2 行目を追加するだけです。)

4. シェルコマンドのエイリアス

别名不仅仅限于运行其他 Git 子命令 —— 你还可以定义运行其他 shell 命令的别名。这是一个用来处理一个反复发生的、罕见和复杂的任务的很好方式：一旦你确定了如何完成它，就可以在别名下保存该命令。例如，我有一些复刻fork的开源项目的仓库，并进行了一些本地修改。我想跟上项目正在进行的开发工作，并保存我本地的变化。为了实现这个目标，我需要定期将来自上游仓库的更改合并到我复刻的项目中 —— 我通过使用我称之为upstream-merge 的别名来完成。它是这样定义的：

upstream-merge = !"git fetch origin -v && git fetch upstream -v && git merge upstream/master && git push"

别名定义开头的 ! 告诉 Git 通过 shell 运行这个命令。这个例子涉及到运行一些 git 命令，但是以这种方式定义的别名可以运行任何 shell 命令。

（注意，如果你想复制我的 upstream-merge 别名，你需要确保你有一个名为 upstream 的 Git 远程仓库，指向你已经分配的上游仓库，你可以通过运行 git remote add upstream 来添加一个。）

5、 可视化提交图

如果你在一个有很多分支活动的项目上开发，有时可能很难掌握所有正在发生的工作以及它们之间的相关性。各种图形用户界面工具可让你获取不同分支的图片并在所谓的“提交图表”中提交。例如，以下是我使用 GitLab提交图表查看器可视化的我的一个仓库的一部分：

GitLab commit graph viewer

如果你是一个专注于命令行的用户或者发现分支切换工具让人分心，那么可以从命令行获得类似的提交视图。这就是 git log 命令的 --graph 参数出现的地方：

Repository visualized with --graph command

以下命令可视化相同仓库可达到相同效果：

git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)%Creset' --abbrev-commit --date=relative

--graph 选项将图添加到日志的左侧，--abbrev-commit 缩短提交的 SHA 值，--date=relative 以相对方式表示日期，以及 --pretty 来处理所有其他自定义格式。我有个 git lg 别名用于这个功能，它是我最常用的 10 个命令之一。

6、 更优雅的强制推送

有时，你越是想避开越避不开，你会发现你需要运行 git push --force 来覆盖仓库远程副本上的历史记录。你可能得到了一些反馈，需要你进行交互式变基rebase，或者你可能已经搞砸了，并希望隐藏“罪证”。

当其他人在仓库的远程副本的同一分支上进行更改时，会发生强制推送的危险。当你强制推送已重写的历史记录时，这些提交将会丢失。这就是 git push --force-with-lease 出现的原因 -- 如果远程分支已经更新，它不会允许你强制推送，这确保你不会丢掉别人的工作。

7、 git add -N

你是否使用过 git commit -a 在一次行动中提交所有未完成的修改，但在你推送完提交后才发现 git commit -a 忽略了新添加的文件？你可以使用 git add -N (想想 “notify”) 来解决这个问题，告诉 Git 在第一次实际提交它们之前，你希望在提交中包含新增文件。

8、 git add -p

Git を使用する場合のベスト プラクティスは、バグの修正や新しい機能の追加など、各コミットに論理的な変更が 1 つだけ含まれるようにすることです。ただし、作業中に、リポジトリ内の変更に複数のコミットが必要になる場合があります。各コミットに適切な変更のみが含まれるように、どうすれば物事を分離できるでしょうか? git add --patch があなたを救います!

このフラグにより​​、 git add コマンドは作業コピー内のすべての変更を調べ、各変更をコミットするか、スキップするか、決定を延期するかを尋ねます (コマンドの実行後に ? を選択すると、他の変更をさらに確認できます)強力なオプション）。 git add -p は、適切に構造化されたコミットを作成するための優れたツールです。

9. git チェックアウト -p

git add -p と同様に、git checkout コマンドも --patch または -p オプションを受け入れます。これにより、ローカルの作業コピー内の変更の各「チャンク」が表示され、それを破棄できるようになります。ローカルの作業コピーを変更前の状態に復元します。

これは本当に素晴らしいです。たとえば、大量のデバッグ ログ ステートメントを引き起こすバグを追跡している場合、バグを修正した後、最初に git checkout -p を使用して新しいデバッグ ログをすべて削除し、次に git add -p を使用してバグ修正を追加できます。エレガントでよく構成された提出物をまとめるほど満足のいくものはありません。

10. リベース時にコマンドを実行する

一部のプロジェクトには、リポジトリ内のすべてのコミットが動作状態になければならないというルールがあります。つまり、すべてのコミットで、コードがコンパイルできるか、テスト スイートが失敗せずに実行できる必要があります。 ブランチで作業しているときはこれは難しくありませんが、何らかの理由で rebase が必要になった場合は、リベースされた各コミットをステップ実行して、誤って導入しないようにする必要があります。休憩、このプロセスは退屈です。

幸いなことに、git rebase はすでに -x または --exec オプションをオーバーライドしています。 git rebase -x は、リベースで各コミットが適用された後にこのコマンドを実行します。したがって、たとえば、npm run testing を使用してテスト スイートを実行するプロジェクトがある場合、 git rebase -x npm run testing は、リベース中の各コミットの後にテスト スイートを実行します。これにより、リベースされたコミットでテスト スイートが失敗するかどうかを確認できるため、テスト スイートが各コミットで引き続き成功することを確認できます。

11. 時間ベースの改訂引用

多くの Git サブコマンドは、コマンドがリポジトリのどの部分に作用するかを決定するためのリビジョン パラメータを受け入れます。これは、特定のコミットの SHA1 値、ブランチの名前、または HEAD (現在のチェックアウトを表す) などの記号名にすることもできます。ブランチの最後のコミット）、これらの単純な形式に加えて、指定した日付または時刻をパラメータとして追加して、「今回の時刻への参照」を示すこともできます。

この機能はいつか非常に便利になるでしょう。最新のバグに対処して、「昨日はこの関数は問題ありませんでしたが、何が変更されたのでしょうか?」と自分に問いかけるときは、コミットがいつ変更されたかを把握しようとして git ログ出力の全画面を見つめる代わりに、ただ git を実行するだけです。 diff HEAD@{yesterday} をクリックすると、昨日以降のすべての変更が表示されます。これは、正確な日付 (例: git diff HEAD@{'2010-01-01 12:00:00'}) だけでなく、より長い期間 (例: git diff HEAD@{'2 months ago'}) にも機能します。

これらの日付ベースのリビジョン パラメータは、リビジョン パラメータを使用する Git サブコマンドでも使用できます。どの形式を使用するかについては、gitrevisions のマニュアル ページに詳細が記載されています。

12. 全知のレフログ

リベース中にコミットを強制終了しようとして、そのコミットに何かを保持する必要があることがわかったことがありますか?この情報は決して取得できず、再作成することしかできないと思われるかもしれません。ただし、ローカルの作業コピーにコミットすると、コミットは reflog に追加され、引き続きアクセスできます。

git reflog を実行すると、ローカル作業コピー内の現在のブランチのすべてのアクティビティのリストが表示され、各コミットの SHA1 値が得られます。リベース時に放棄したコミットを見つけたら、 git checkout を実行してそのコミットにジャンプし、必要な情報をコピーしてから git checkout HEAD を実行してブランチの最新のコミットに戻ることができます。

13. 後片付け

ああ！ 私の基本的な数学スキルは Git スキルよりも劣っていることがわかりました。 Git はもともと 2005 年にリリースされたため、12 年ではなく今年で 13 年目になることになります。その間違いを補うために、私たちを 13 人に変えるヒント 13 を紹介します。

ブランチベースのワークフローを使用する場合、長期的なプロジェクトに取り組むときに、マージ時に各ブランチをクリーンアップしないと、大量のブランチができてしまいます。そのため、目的の枝を見つけるのが難しく、枝が林立していて見つけることができません。さらに悪いことに、多数のアクティブなブランチがある場合、ブランチがマージされる (安全に削除できる) か、まだマージされていないため放っておくべきかを判断するのは非常に面倒になる可能性があります。幸いなことに、Git が役に立ちます。 git Branch --merged を実行して現在のブランチにマージされたブランチのリストを取得するか、 git Branch --no-merged を実行して他のブランチにマージされたブランチを確認します。デフォルトでは、ローカル作業コピー内のブランチがリストされますが、コマンドラインに --remote または -r 引数を含めると、リモート リポジトリにのみ存在するマージされたブランチもリストされます。

重要: git Branch --merged の出力を使用して、マージされたブランチをクリーンアップする場合は、その出力に現在のブランチも含まれることに注意する必要があります (結局のところ、この現在のブランチは現在のブランチにマージされます)支店！）。破棄する前に必ずブランチを除外してください (忘れた場合は、ヒント 12 を参照して、reflog がブランチを元に戻すのにどのように役立つかを確認してください。お役に立てば幸いです...)。

以上が内容です

これらのヒントの少なくとも 1 つが、革新と新機能の追加を続ける 13 年前のプロジェクトである Git について何か新しいことを教えてくれれば幸いです。あなたのお気に入りの Git トリックは何ですか?

---

以上が13 の実践的な Git のヒントの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。