Zenn
👣

個人的Gitメモ

2023/12/01に公開
Git
tech

この記事はごった煮 Advent Calendar 2023の1日目の記事です。
Gitの使い方説明というよりかは、私がどんな感じでGitを使っているかに焦点を当てようと思います。

Gitの基本概念の説明

は、ここではしません。
Mixiの新卒研修資料が非常によくできているのでそちらを見てください。
この世のすべてが書いてあります（ぐるぐる目
https://speakerdeck.com/mixi_engineers/2023-git-training

ブランチ戦略について

Github flowを採用しています。
きっかけはお仕事がこれで思いのほか悪くなかったから、です。
念のため説明しておくと、

  • mainブランチを設ける
  • そこに対していくつもPull requestを作ってマージ
  • マージされたそばからリリースされる

自力でCI/CD構築できるというのもあり、developブランチに集約してまとめてリリースするGit flowよりも身動きがとりやすくていいな、と感じてます。

普段使いの設定

まずは設定ファイルをお見せします。
これはLinuxであれば~/.gitconfigから確認できるものになります。
私の場合は複数のPCで使いまわせるように汎化してテンプレート化したものがあり、今回載せるのはそれの一部になります。
各項目の説明は後で書きます。

.gitconfig
[user]
        name = (ユーザ名)
        email = (自分のメールアドレス)
[pull]
        rebase = true
[init]
        defaultBranch = main
[commit]
        gpgsign = true
[tag]
        gpgsign = true
[core]
        editor = emacsclient

各項目の説明

[user]

name

Gitでコミットする際に使用するユーザ名を設定します。これは作業者の識別子となり、コミット履歴に表示されます。

email

Gitでコミットする際に使用するメールアドレスを設定します。このメールアドレスもまた、コミット履歴に表示され、識別子としての役割を果たします。公開で物を作るならば第三者から見えてもいいメールアドレスを使おう。

の結果nameとemailが表示されている画像

[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オプションを使え

詳しくは下記記事を参照してください
https://onk.hatenablog.jp/entry/2022/12/18/000000

pre-commit hookは好きじゃないが必要なら使え

pre-commit hookは、コミットの前に自動でテストやフォーマットのチェックを行う便利な機能です。
個人的には、Git操作をスムーズに行い、コミットとテストを別々に扱うべきだと考えています。これは、作業の流れを速やかに保つための選択です。ただし、プロジェクトやチームのニーズによっては、pre-commit hookを使ってコードの品質を確保することも一つの方法です。もし採用する場合は、実行時間が短く、本当に必要なテストだけを行うように設定することが望ましいです。

PR出す前にgit diff --shortstat (PR先のブランチ名)しろ

あまりに大きな差分はレビューする人にとってかなり負担になります。
また、修正必要箇所が増えるとマージまでに要する時間がどんどん増えていきます。
目安としては追加600行を目安にしてください。どんなに膨らんでも1000行までにしてほしいかも？
あまりに大きくなりそうな場合は、タスク範囲やタスク目標が大きすぎます。
作業前にまずタスク範囲を小さく、かつ単純化すべきです。

追記

emacsclientを使う

core.editor=emacsだと起動時に待たされて微妙なので、別でemacs --daemonを起動しておいて、core.editor=emacsclientすると快適だとアドバイスをいただきました！

Discussion