個人的Gitメモ
この記事はごった煮 Advent Calendar 2023の1日目の記事です。
Gitの使い方説明というよりかは、私がどんな感じでGitを使っているかに焦点を当てようと思います。
Gitの基本概念の説明
は、ここではしません。
Mixiの新卒研修資料が非常によくできているのでそちらを見てください。
この世のすべてが書いてあります(ぐるぐる目
ブランチ戦略について
Github flowを採用しています。
きっかけはお仕事がこれで思いのほか悪くなかったから、です。
念のため説明しておくと、
- mainブランチを設ける
- そこに対していくつもPull requestを作ってマージ
- マージされたそばからリリースされる
自力でCI/CD構築できるというのもあり、developブランチに集約してまとめてリリースするGit flowよりも身動きがとりやすくていいな、と感じてます。
普段使いの設定
まずは設定ファイルをお見せします。
これはLinuxであれば~/.gitconfig
から確認できるものになります。
私の場合は複数のPCで使いまわせるように汎化してテンプレート化したものがあり、今回載せるのはそれの一部になります。
各項目の説明は後で書きます。
[user]
name = (ユーザ名)
email = (自分のメールアドレス)
[pull]
rebase = true
[init]
defaultBranch = main
[commit]
gpgsign = true
[tag]
gpgsign = true
[core]
editor = emacsclient
各項目の説明
[user]
name
Gitでコミットする際に使用するユーザ名を設定します。これは作業者の識別子となり、コミット履歴に表示されます。
Gitでコミットする際に使用するメールアドレスを設定します。このメールアドレスもまた、コミット履歴に表示され、識別子としての役割を果たします。公開で物を作るならば第三者から見えてもいいメールアドレスを使おう。
[pull]
rebase = true
そもそも、git pull
コマンドの実態は、git fetch && git merge
の複合です。
そのうち、後者をrebaseに変更し、git pull && git rebase
にしてしまうのが本設定項目になります。同様の挙動を実現するためにgit pull --rebase
とすることも可能です。
[init]
defaultBranch = main
新しいリポジトリを初期化した際のデフォルトのブランチ名をmainに設定します。以前はmasterが標準でしたが、最近ではmainがよく使用されるようになっています。
[commit]
gpgsign = true
コミットを行う際に、GPGを使って署名を行うように設定します。
別途user.signingkey
の設定が必要です。
[tag]
gpgsign = true
タグを作成する際に、GPGを使って署名を行うように設定します。
別途user.signingkey
の設定が必要です。
[core]
editor = emacsclient
Gitで使用するデフォルトのエディタをEmacs(emacsclient)に設定します。
事前にemacs --daemon
を動かしておく必要があります。
コミットメッセージの編集など、Gitがエディタを必要とする場面でEmacsが起動されます。
vimだろうがnanoだろうがなんでも大丈夫です。完全に好み。
運用
かなり思想
pullするなrebaseしろ
プロジェクトにおいて、コードの履歴をスッキリと保つために、git merge
やgit pull
よりもgit rebase
やgit pull --rebase
の方が好きです。
ージとリベースの主な違いは、履歴の整理にあります。マージは複数の履歴を一つに統合しますが、リベースはあたかもこれらの変更が最初から順序良く行われたかのように履歴を整えます。これにより、履歴が読みやすく、追跡しやすくなります。
デメリットも当然あります。歴史改変をした結果、リモート(Github等)と違う歴史を歩んだことになり、そのままではpushできなくなります。Force pushの出番ですね。Force pushが悪い意味でネタにされがちですが、こういった場面では必要になります。要は適切な使い方をしましょうね、ということです。
push -f
するな--force-with-lease --force-if-includes
オプションを使え
詳しくは下記記事を参照してください
pre-commit hookは好きじゃないが必要なら使え
pre-commit hookは、コミットの前に自動でテストやフォーマットのチェックを行う便利な機能です。
個人的には、Git操作をスムーズに行い、コミットとテストを別々に扱うべきだと考えています。これは、作業の流れを速やかに保つための選択です。ただし、プロジェクトやチームのニーズによっては、pre-commit hookを使ってコードの品質を確保することも一つの方法です。もし採用する場合は、実行時間が短く、本当に必要なテストだけを行うように設定することが望ましいです。
git diff --shortstat (PR先のブランチ名)
しろ
PR出す前にあまりに大きな差分はレビューする人にとってかなり負担になります。
また、修正必要箇所が増えるとマージまでに要する時間がどんどん増えていきます。
目安としては追加600行を目安にしてください。どんなに膨らんでも1000行までにしてほしいかも?
あまりに大きくなりそうな場合は、タスク範囲やタスク目標が大きすぎます。
作業前にまずタスク範囲を小さく、かつ単純化すべきです。
追記
emacsclientを使う
core.editor=emacs
だと起動時に待たされて微妙なので、別でemacs --daemonを起動しておいて、core.editor=emacsclient
すると快適だとアドバイスをいただきました!
Discussion