個人的Git利用法
「Gitの使い方」みたいな初心者向け記事は一杯あるのですが、私は割とそういう記事に書かれているのとは違うやり方を使うので、ちょっと書いてみます。
このやり方を真似すべき、とは言いません。ただ、こんなやり方もあるんだなと思ってもらえればいいかと思います。
割とコミット履歴改竄してしまう派なので気に食わない人も多いと思います。リモートリポジトリに影響を与える操作に関しては、共同開発ならコミュニティやリポジトリオーナーの意向に合わせるので、必ずしもこの通りにする訳ではありません。
リモートリポジトリを作る前にローカルで初期化する
個人プロジェクトは大抵の場合、リモートリポジトリを作成してからclone
ではなく、ローカルである程度作業してからリモートリポジトリを作ってpush
することが多いです。
ローカルリポジトリ初期化まで含めてやってくれるcliツールもありますし。cargoとか。
そのため、こんな感じでコマンドを実行することが多いです
git init
git commit --allow-empty -m "Initial commit."
git remote add origin git@github.com:kazatsuyu/example.git
# ここでpushする前にリモートリポジトリを作っておく
git push --set-upstream origin master
最近はgithubのデフォルトブランチがmainになったりしたようですが、少なくともgitコマンドが変わらない限りわざわざmasterをmainにリネームするつもりはないです。
共同開発の場合、ローカルのデフォルトブランチは消す
masterやmainなどのデフォルトブランチは、その性質上頻繁に更新されます。
ですので、たまたまclone
した時点でorigin/master
と同じコミットを指していただけのブランチを保持する意味はないと私は考えています。1分後には変わっている可能性すらありますし。
個人プロジェクトの場合はmasterのままコミットを増やすこともありますが、共同開発の場合は消してしまいます。
git clone git@example.com:foo/bar.git
cd foo
git switch -d
git branch -d master
リモートの最新に切り替えたい時は、
git switch -d origin/master
で可能です。
HEADにコミットする
特定の機能の実装やバグ修正などに着手するとき、トピックブランチを作らずにorigin/master
に移動して作業開始することが多いです。
ある程度作業が一段落してコミットをする時、デタッチされた状態なのでHEADだけが移動することになりますが、特に気にせず実行します。
コミットが終わってから
git switch -c feature/foo
としてトピックブランチの作成と切り替えを行うことも多いです。
pull
は使わない
まあこれは同じようにやっている人も多いかと思いますが、pull
は利用しません。
そもそもローカルにmaster
があるからpull
をしなければいけないのです。master
を消してしまえば必要がありません。
自分が作業中のトピックブランチならpull
しなければいけないようなこともまずありませんし。
リモートと同期をしたい場合はこうです。
git fetch
必要に応じて--prune
, --recurse-submodules
, --all
などのオプションも利用します。
fetch
はリモートブランチを更新するだけなので、fetch
を終えた後にコミットを移動したい時はswitch
を使います。
rebase
は結構使う
rebase
は使わない方がいい、という主張があることは知っていますが、私は頻繁にrebase
を使います。
もちろんデフォルトブランチやリリースタグの付いた場所をrebase
したりはしませんが、ローカルでの作業中やトピックブランチでの作業中はよくrebase
を実行します。
これは好みの問題だろうと思うので特に推奨はしません。業務ではMR中(業務はgitlabを使っている)にもrebase
したりしますが、これはプロジェクトメンバーと話し合ってOKかどうか決めておくべきことですね。
stash
は短時間で使う
1ヶ月前にstash
したコードが何なのかなんて思い出せないので、長期に渡って保持するつもりがある作業コードは素直にトピックブランチを生やします。
stash
を使うよくあるケースは、「origin/master
から作業を開始するつもりだったのに別のトピックブランチから作業を始めてしまった」みたいな時です。
switch
で切り替えることができるケースもありますが、複雑な差分が生まれるとswitch
はできないので、その場合はstash
してからswitch
して、即座にstash pop
をします。
たまにstash pop
でコンフリクトが発生することもありますが、そういう場合は何をどうやってもコンフリクトするので素直に直します。
また、stash pop
の途中でコンフリクトが発生した場合、コンフリクト解消してもスタッシュが残り続けてしまうのでstash drop
で消します。
commit -a
は使わない
これは同じようにやってる人も多いと思いますが、事故防止のためにもadd
とcommit
は分けて行います。
まあコミットの段階なら事故っても直せばいいんですが。push
してしまってもrebase
する派なのでmaster
に入らない限りはrebase
やcommit --amend
で直しちゃいますが。
とは言え事故ったことに気づかないこともありますから、差分を確認しながらadd
を行って、その後commit
をします。
add
はVSCodeのGUI上で行うことが多いです。commit
はコマンドラインから叩きます。
GIT_PS1_DESCRIBE_STYLE=branch
を使う
git-promptの話です。
デフォルトの設定だと__git_prompt
はデタッチされた状態で((deadbee...))
のようにコミットハッシュを表示するのですが、こうしておくと((feature/foo))
や((remotes/origin/master))
のように表示してくれるので、私のようにだいたいいつもデタッチしている者には合っています。
Discussion