Gitスキルを次のレベルに引き上げる10のヒント

最近、 Gitの基本とチームでのGitの使い方に関するチュートリアルを公開しました。以前紹介したコマンドは、開発者がGitの世界で生き残るのに十分です。この記事では、時間をより効率的に管理する方法と、Gitが提供するさまざまな機能を最大限に活用する方法を探ります。

注: この記事の一部のコマンドには、角括弧で囲まれた部分が含まれています（例: git add -p [file_name] ）。これらの例では、数字や識別子などを挿入する必要がありますが、角括弧はそのままにしてください。

1. Gitの自動補完

コマンドラインでGitコマンドを使用する場合、毎回手動でコマンドを入力するのは非常に面倒です。この問題は、オートコンプリートを有効にするだけで簡単に解決できます。

Unix システムでは、次のコマンドを実行してスクリプトを取得します。

 cd ~
カール https://raw.github.com/git/git/master/contrib/completion/git-completion.bash -o ~/.git-completion.bash

次に、 ~/.bash_profileファイルに次のコードを追加します。

 [ -f ~/.git-completion.bash ] の場合;
 ~/.git-completion.bash
フィ

前にも述べたように、繰り返しますが、Git が提供するすべての機能を使用したい場合は、必ずコマンドラインの使用に切り替える必要があります。

2. Gitでファイルを無視する

Git リポジトリに表示されるコンパイル済みファイル ( .pycなど) にうんざりしていませんか?

それとも、単に Git に追加することに関して限界点に達しただけでしょうか?

Git に特定のファイルやディレクトリを無視させる方法が追加されました.gitignoreファイルを作成し、Git に追跡させたくないファイルとディレクトリをリストアップするだけです。感嘆符 (!) を使って例外を示すこともできます。

 *.pyc
 *。EXE
 my_db_config/
 !main.pyc

3. 誰が私のコードを改ざんしたのでしょうか?

問題が発生すると、つい他人のせいにしてしまいがちです。本番サーバーに不具合が発生した場合、 git blameコマンドを使うだけで簡単に原因を特定できます。

このコマンドは、ファイル内の各行の作成者、最後の変更後に行われたコミット、およびそのコミットのタイムスタンプを表示します。

 git blame [ファイル名]

下の画像は、大規模な倉庫でこのコマンドを使用するとどうなるかを示しています。

4. 倉庫の履歴を確認する

前のチュートリアルでは、 git logコマンドの使い方を学びました。ただし、他に知っておくべき 3 つのオプションがあります。

--oneline -- 各コミット間に表示される情報を、縮小されたハッシュ値とコミットメッセージに圧縮し、 1 行に表示します。
--graph — このオプションは、出力インターフェイスの左側にテキストベースのグラフィカル表現で履歴を表示します。
単一のブランチの履歴のみを参照する場合、この機能は役に立ちません。
--all —— すべてのブランチの履歴を表示します

これは、上記のすべてのコマンドを一緒に使用した場合の効果です。

5. 提出物を決して失わないでください。

例えば、コミットしたくないコードをコミットし、ハードリセットを使って以前の状態に戻したとします。後になって、その過程で他の情報が失われていることに気づき、元に戻したい、あるいは少なくとも確認したいと思ったとします。`git git reflogコマンドを使えば、このような作業を簡単に行うことができます。

シンプルなgit logコマンドは、最新のコミットだけでなく、前のコミット、その前のコミットなどのコミットも表示します。

` git reflog 、すべてのヘッド移動に関する情報を表示します。これはローカルであり、リポジトリの一部ではないため、プッシュやマージには含まれません。

git log使用すると、取得するコミット情報はリポジトリの一部になります。

ただし、 git reflogコミットメッセージ ( b1b0ee9 – HEAD@{4} ) が表示されましたが、これはハードリセットを使用したときに失われたものでした。

6. ファイルへの部分的な変更を一時的に保存する

一般的に、機能ベースのコミットを作成するのが良い方法です。つまり、各コミットは新機能またはバグ修正を表す必要があります。2つのバグを修正したり、複数の新機能を追加したりしたにもかかわらず、これらの変更をコミットしなかった場合はどうなるでしょうか？このような場合、これらの変更を1つのコミットにまとめることができます。しかし、さらに良い方法があります。ファイルを個別にステージングし、個別にコミットするのです。

たとえば、ファイルに複数の変更を加え、それらを個別にコミットしたい場合は、 addコマンドに-pオプションを追加できます。

 git add -p [ファイル名]

実際にやってみましょう。ファイルfile_nameに3行のテキストを追加しました。1行目と3行目だけをコミットしたいとします。まずはgit diffで表示される結果を見てみましょう。

次に、add コマンドに-pオプションを追加すると何が起こるかを見てみましょう。

Git はすべての変更が同じ対象を対象としていると想定しているため、すべてを 1 つのブロックにまとめてしまうようです。以下のオプションがあります。

ブロックをキャッシュするにはyを入力してください
入力nはこのブロックをキャッシュしません
ブロックを手動で編集するには、「 eと入力します。
終了するか次のファイルに進むには、「 dと入力します。
このブロックを分割するにはsを入力してください

私たちにとっては、それをいくつかの部分に分割し、いくつかを選択的に追加し、他の部分を無視したいと考えています。

ご覧の通り、1行目と3行目を追加し、2行目を省略しています。リポジトリのステータスを確認して、後でコミットすることができます。

7. 複数の提出物を結合する

コードをレビューに提出し、プルリクエストを作成すると（オープンソースプロジェクトではよくあることですが）、コードが承認される前に変更を求められることがよくあります。いくつか変更を加えた後、次のレビューでさらに多くの変更を求められることがあります。どれだけの変更が待っているか分からず、気が付くと複数のコミットを追加していることになります。理想的には、 rebaseコマンドを使用して、すべての変更を1つのコミットにマージできます。

 git rebase -i HEAD~[コミット数]

最後の 2 つのコミットをマージする場合は、次のコマンドを使用する必要があります。

 git rebase -i HEAD~2

このコマンドを実行すると、インタラクティブなインターフェースが開き、直近2つのコミットが表示され、どのコミットをsquashするか尋ねられます。理想的には、最新のコミットpick 、それ以前のコミットとsquashようにしてください。

次に、マージされたコミットの説明を入力するよう求められます。このプロセスにより、コミット履歴が書き換えられます。

8. まだコミットされていない変更を保存する

例えば、バグを修正したり新機能を追加したりしているときに、突然作業内容を公開するように求められることがあります。しかし、現在の作業内容はまだコミットできる状態ではなく、この段階では（すべての変更を元に戻さない限り）公開できません。このような状況では、 git stashが役に立ちます。`stash` コマンドは、基本的にすべての変更を将来の使用のために保存します。変更を保存するには、次のコマンドを実行します。

 git スタッシュ

一時リストを表示するには、次のコマンドを実行します。

 git スタッシュリスト

これらの変更を保存したくない、または元に戻したい場合は、次のコマンドを使用します。

 git stash 適用

最後のスクリーンショットでは、各セーブデータに識別子（一意の番号）が付与されていることがわかります（ただし、ここでは一度しかセーブしていません）。特定のセーブデータのみを使用する場合は、 applyコマンドの後に識別子を指定する必要があります。

 git stash stash@{2} を適用

9. 不足しているコミットを確認する

reflog失われたコミットを確認する手段ですが、大規模なリポジトリでは機能しません。そこでfsck (ファイルシステムチェック) の出番です。

 git fsck --lost-found

ここで、不足しているコミットを確認できます。`git git show [commit_hash]を使用すると、これらのコミットに含まれる変更内容を確認できます。また、 git merge [commit_hash]を使用すると、コミットを復元できます。

git fsckはreglogにはない利点が1つあります。例えば、リモートブランチを削除してリポジトリをクローンした場合、 fsckコマンドを使ってそのリモートブランチを検索し、復元することができます。

10. チェリーピックコマンド

最もエレガントな Git コマンドを最後に残しました。`cherry cherry-pick 、その名前がその機能を完璧に表しているため、私のお気に入りの Git コマンドです。

簡単に言うと、 cherry-pickは、異なるブランチからコミットを選択し、現在のブランチにマージすることを指します。2つ以上のブランチを並行して開発している場合、すべてのブランチでバグに気付くことがあります。1つのブランチでバグを解決した場合、チェリーピックを使用することで、他のファイルやコミットに影響を与えることなく、そのコミットを他のブランチにマージできます。

このコマンドが使えるシナリオを想像してみましょう。2つのブランチがあり、コミットb20fd14: Cleaned junkをチェリーピック方式で別のブランチにコピーしたいとします。

コミットを配置するブランチに切り替えて、次のコマンドを実行します。

 `git チェリーピック [コミットハッシュ]`

この例では、 cherry-pickを使用しても問題はありませんが、このコマンドは競合を引き起こす可能性があるので、注意して使用してください。

まとめ

この記事を読み終えた今、これらのヒントがあなたの Git スキルを次のレベルに引き上げてくれると信じています。

Git は最高です。考えられるあらゆることが可能になります。

そのため、定期的にGitスキルに挑戦してみましょう。きっと何か新しいことを学べるはずです。

オリジナルリンク: http://blog.jobbole.com/75348/

DUICUO