リポジトリ整理に使う git 操作

先日リポジトリ整理記念でこのサイトのページを一個更新しました。 参考になるかわからないですが、整理に使うコマンドでもビボって置こうかなと

note

ビボる: 今考えついた言葉。 備忘録を書く。 メモっておくとなんら変わらない。

warning

当記事では個人運用しているリポジトリに有用な情報を載せています。
複数人で管理するリポジトリについて、全く考慮してないことを注意してください。

今日のひとこと

ぷぺぺぽぴー聴き比べてたんだけど、2024 と 2014 の札幌記念が一番上手だとおもた。
そもそも金管吹こうと思ったことあるけど、あんまりうまく吹けなかった。 しかし、久々に sax 吹いたけど、音出たからびびった。
まだ吹けそう。

40mP さんの曲ひっさびさに聴いた気がする。

メインブランチを綺麗にしたい

即興で作ったリポジトリは基本的にメインブランチが汚いです。私の場合 メインブランチを綺麗にする方法ですが、rebaseを使うよりもorphanブランチで一つずつ作る方が安全でいいのではないだろうかと思いました。

orphan ブランチ

git checkout --orphan new_main
# first commit(init commit)を作っておく
git commit --allow-empty -m "init-commit"

この状態でコミットログをみると

* commit 5aa02c1fcbd01b6b2b2b9fbe8d4ce8274f31042e

      init-commit

* commit b7df9b6137012e2a9dc986f506f78f0f21f85bfb
|
|     next-commit3
|
* commit a735303da15fee2598b5bef5b3cab78db2ef8eb2
|
|     next-commit2
|
* commit 6445f41b7fad4369e70fe74d59ab95d2dcb23b9d
|
|     next-commit
|
* commit 9dd2d68c25ed16f037baa7d281963e36949e6732

      init-commit

(コマンドはgit log --graph --all、出力から Auther と Date は抜いてます)

線が繋がっていないのでログが途切れている、別の次元にいる状態になります。

note

orphan で作ったブランチに移動した場合、全てのファイルが未追跡状態として残ります。 git clean -fdでリポジトリを綺麗にしてから、作業を始めましょう。

tip

愚かな共有です。 git clean -nfdしてて、消えないなと思ったから、手動でrmしてました。 -nは dryrun です。
消えるファイルがあって怖い場合は dry run をしたり、最悪バックアップするのもありだと思います。安全第一。ご安全に、ヨシ!
何をみてヨシとしたんですか?

新しいブランチでリベースする

新しいブランチでリベースを行うと、歴史が繋がります。 これは first-commitを空コミットに置き換える時に有用 です。

note

英語記事ですが、こちらが詳しいです。
How do I git rebase the first commit?

古いブランチから cherry-pick する

cherry-pick を行えば、古いブランチからコミットを持ってくることができます。

git cherry-pick 1b99fe
# 複数選択可能
git cherry-pick 1b99fe..295444
# --no-commit で、コミット編集もいける
git cherry-pick 1b99fe --no-commit

時間があれば、--no-commitでコミットを編集することもできます。
ステージングされた状態になるため。

--no-commitで複数のコミットをcherry-pickして、コミットを束ねることができます。

整理して思ったこと

warning

この章は それって私の感想ですよね? が含まれます。

整理してて思ったことは何個かあります。 まず、ブランチの使い方です。

マージ方法を考えましょう。
無駄なコミットを束ね、綺麗なコミットメッセージを残すことができるのがsquashマージとなります。

main ブランチはもちろんのこと、dev ブランチなどではコミットメッセージは綺麗な方がいいと思います。 後から見返して何やってたかわかるのが重要なので 「作業もっと分割できそうだな」って思ったらすかさずブランチを作り、squash マージで束ねていきましょう。
まとめすぎてはいけないけど、バラバラだとコミットメッセージ考えるのが大変。 rebase はやらないに越したことがない

ブランチ名

ブランチ名にも規則性をつけましょう。 feature ブランチ(機能追加)、setup ブランチ(プロジェクトの初期セットアップ)、modify ブランチ(調整)、fix ブランチ(修正)。 英語がいい、日本語がいいは正直関係ないと思います。 deepl 優秀だし。

大切なのは目的が定まってることです。 このブランチでどこまでやるか線引きするといいと思います。 そうすれば、最終的にはコミットメッセージがつけやすくなると思います。

note

関数名とか変数名とかも重要なのはこれだと思う。
何ができるのか(関数)、なんのためにあるのか(変数)、名前ではっきりさせたいよね。

まぁこれができたら苦労しないわけで

苦労して初めてわかることもあるので、「俺は日記のようはヘマはしない!」 なんて思わないで、 とにかく適当に管理するといいと思います。 この項目で書いてあるのは「やればわかる」だと思うので。

でも日記さんと同じヘマはしない方がいい。 結構レベル低いこと言ってるなと自覚してる

どうやってコミットを綺麗にするか

前の項目で~~長いお気持ち表明してましたが、~~コミット履歴を綺麗にする話をしました。 これについて、OSS のプロジェクトで使われているガイドラインなど参考にすると良いのかもしれません。

まとめ

地味な作業ほど重要であり、QoL をあげられると信じてる。