汎用性の高いと思われるものから紹介してゆきます。

1.エイリアス

gitをCLIで操作しようと思ったら必須の設定ですね。
gitコマンドを省略できたり、関数を実行できたりと便利な設定です。

設定方法は以下の通りです。

~/.gitconfig

[alias]
co = checkout
hi = !"f(){ echo hi; };f"

上記例では、coというエイリアスにcheckoutを、hiというエイリアスに自作の関数を設定しています。
右辺の先頭に!をつけると、自作の関数を割り当てることができます(関数の具体的な書き方については割愛)

この状態でエイリアスを実行してみるとこんな感じになります。

$ git co develop
Switched to branch 'develop'
$ git hi
hi

そしてもっと言うと、git自体のエイリアスもつくっちゃうとよりストレスフリーになります。

$ echo "alias g=git" >> ~/.bashrc
$ . ~/.bashrc

で設定&反映可能です。

git checkout developが、g co developで実行できるようになりました。

2.プロンプト・TAB補完

2番はgitの設定というかは、gitのためのbashの設定です。

てゆうかプロンプトってなんぞ？ってなる方いるかもしれませんが、ようするにターミナルの表示設定のことです。
例えばg b(ranch)ってしなくても、カレントブランチを常に表示してくれるようにできたり、g st(atus)ってしなくても、差分を常に表示してくれるようにできたりします。
設定方法については割愛します。

次TAB補完ですね。
例えば、カレントブランチがdevelopの状態からfeature/hogefugapiyoという、ちょっと名前の長いブランチにg coしたいとしたときに、

$ g co fea<tab>
$ g co feature/hogefugapiyo

みたいな感じで補完して欲しいですよね？

そのための設定がTAB補完設定です。
設定方法については割愛です。

3.git hooks

これは設定というかは、tipsですね。

git hooksは、gitの特定のコマンドをトリガー(フック)にして任意の処理を実行できる仕組みのことです。

例えば、コーディング規約で、pythonのスクリプトはflake8でリントされてないといけないルールがあったとします。
コミット前にちゃんとflake8の確認をしてからコミットしないといけませんが、どうしても実施漏れが起きちゃう。みたいな状況が起こっているとします。

こういう時にgit hookは便利です。
g commitをフックにして、ステージングされたファイルを勝手にflake8でチェックしてくれるスクリプトを書けば、コミット時に勝手にflake8を走らせるなんてことができます。
どこにそのスクリプトを書くかというと、ローカルリポジトリのルートディレクトリに.git/hooksってディレクトリがあると思います。そしてその下には.sampleで終わるシェルスクリプトがなにやらたくさん入っていると思います
その中に、pre-commit.sampleってファイルがあると思うので、それをpre-commitって名前にリネームして、その中に処理を書きます。
シバンでpythonのインタプリタを指定すると、pythonでも処理書けますが、シェルスクリプトで書く方が環境依存が少ないのでオススメです。

ただしこれ、不便な点があって、.gitフォルダってgitの管轄外なんですよね。
なのでプロジェクトとしてその辺徹底するためにはhuskyっていうnodeのパッケージが便利なんですがここでは割愛します。

4.includeディレクティブ

本題の前に、dotfilesってご存知でしょうか。~/配下の.(ドット)から始まるファイル群、およびそれらをgitで管理しようという営みのことです。そうすると、作業端末が変わってもgit cloneしてくればいつもの作業環境がすぐにできあがるというわけです。
そして、dotfilesはgithubなどのpublicなリポジトリに公開することが一般的です。そうした場合に、個人情報やシークレットキーといった他人に知られては困るような情報を含むファイルはあげられません。
例えば~/.aws配下のファイルなんかは絶対に公開しちゃダメだったりしますよね。
.gitconfigも例に漏れず、.gitconfigにユーザ名とかメアドが書いてあって、社内や客先で使ってる情報であればあげられません。

それを解決してくれるのが、[include]ディレクティブです。
説明するより実際の記載例をお見せした方が早いので、そうします。

.gitconfig

[include]
.gitconfig.profile

.gitconfig.profile(ファイル名は任意)

[user]
    name = hogehoge
    mail = hogehoge@email.com

個人情報を記載するためのファイルを用意して、.gitconfigのincludeディレクティブにそのパスを記載します。そうすると、個人情報を別ファイルに分離することができます。
これで、gitconfigをdotfilesで管理できるようになりました。嬉しいですね。

5. autocrlf

最後です。
最後が1番汎用性低いようにランキングしたのでここまで読んでる人も少ないかもしれません。

さて、ちょっとgit詳しい人であれば、autocrlfがこの位置なのは違和感があるんじゃないでしょうか。

あれっ、autocrlfって、結構汎用性高い設定なんじゃないの？って

「git autocrlf」とかでググった結果を見ればそうなんですが、個人的な意見は世論とは違っているので紹介させてもらいます。

というかそもそもautocrlfって何なのっていう話をすると、改行コードの自動変換の設定です。
開発現場でよくwinとmacが混在しちゃってることって多いかと思いますが、そういう時に効果的な設定です。
どういうことかというと、winの改行コードはCRLFで、macはLFなのです。なので例えば、リモートのソース(LF)をwinに落としてきて修正して保存した時に改行コードがCRLFになっちゃったとします。そのソースがそのままリモートにプッシュされてしまうと、意図せぬ差分が大量に検出されてしまいます。
それを防ごうというのがautocrlfというわけです。

設定方法は以下です。

~/.gitconfig

[core]
    autocrlf = true

こうすると、checkoutとcommitの時に改行コードの変換を勝手にしてくれるようになります。

で、ここからが本題なのですが、これを設定しているwinで作業をしていると困る状況があります。
それはコンテナでの開発です。
コンテナに、ホストのローカルリポジトリをそのままバインドして、コンテナで開発しちゃうみたいな開発環境って少なくないと思います。で、だいたいコンテナってliunx系のOS(LF)が入ってることがほとんどですよね。
そうすると、ファイルの改行コードの遷移は以下のような感じになるわけです。

リモート(LF) → ローカル(CRLF) → コンテナ(CRLF)

最終的な開発環境であるコンテナ(LF)に、CRLFのファイルが存在しちゃってますよね。
コンテナでg stすると、何千と差分が出てきてしまいます。
なのでせめてcheckoutするときの自動変換はしてくれなくていいってなるわけです。

さてようやく結論ですが、
個人的にはautocrlfの設定はiuputがいいんじゃないかなって思います。
いやboolじゃないんかいって、なりますよね。

inputを設定すると、commitの時だけCRLF⇔LF変換が行われる(checkoutの時は変換しない)ようになります。

おしまい

なんか全然締まってないですが、以上、gitのおすすめ設定5選でした。
タイトル書くときは勢いでビックリマーク3つもつけちゃいましたが、本文の勢いはというとその片鱗も見せない仕上がりになってしまいました。