1. Qiita
  2. 投稿
  3. Git

gitでローカルブランチにmasterなんて(普通は)要りません

  • 8
    いいね
  • 1
    コメント

理由

  1. GitHubやGitLabなどのおかげで、リモートで直接masterにマージできるようになったから。
    • どうしても、という時以外ローカルのmasterブランチで作業する必要はないはずです。
  2. 間違えてmasterを壊してしまうリスクが更に減るから。
  3. ローカルのmasterブランチをメンテするコストが減るから。

地味なメリットに聞こえるかもしれませんが個人的にはありがたいので最後のものを詳しく説明します。

Gitの仕様上、ローカルのmasterブランチはリモートのmasterブランチを更新しても自動的には更新されません。
現状、git checkout masterしてからgit pullしないと更新できないはずです(他にも方法はありそうな気がしますが割愛します)。

この方法、一瞬でもmasterにチェックアウトしなければならないため、チェックアウトする前のブランチとローカルのmasterの差が大きい場合、ワークツリーの書き換えに時間がかかってしまいます。
一瞬しかそのワークツリーは必要ないのに。 :confused:
さらに、更新前のローカルのmasterとリモートのmasterの差が大きい場合、pullした後のワークツリーの更新にまた時間がかかってしまいます。 :confused:
大きなリポジトリーでは無視できないぐらい遅いかもしれません。 :disappointed:

それに対してリモートのmasterブランチ(origin/master)はgit fetchしただけで更新されます! :thumbsup:
pull するためだけにいちいち checkout する必要はないのです!

ローカルにmasterのない日常

リモートのmasterブランチ、origin/mastercheckout しない限り概ね普通に使えます。
これから紹介するコマンド例の通り、 使う前は都度git fetchしておくと安心です。git-shのaliasなどに追加するのをおすすめします。

origin/master から rebaseしたいときは

git fetch && git rebase origin/master

すればいつでも最新のorigin/masterからrebaseできますし、新しいブランチを作りたいときは

git fetch && git checkout --no-track -b 新しいブランチ origin/master

しましょう。ただし、--no-track オプションをつけるのを忘れないでください!

より安全にやるなら

git fetch && git checkout origin/master
git checkout -b 新しいブランチ

とするとよいでしょう。
間違えて checkout して「detached HEAD」になってしまっても、上記のように慌てず騒がず git checkout -b で新しいブランチを作ればいいのです。

と、言うわけで賛同できる方は「いいね!」して git branch -D master しちゃいましょう!

試したgitのバージョン

ver. 2.1.4