本記事の目的
origin, origin/master, masterの違いがわかるようになること.
早めの結論
違いは以下の通りです.
今からこの表の説明が分かるように説明していきます.
項目 | 説明 |
---|---|
origin | リモートリポジトリの名称 |
origin/master | リモートリポジトリ「origin」のブランチ「master」を追跡するブランチ |
master | ブランチの名称 |
違いが分かると何が嬉しいの?
- コマンドで使う「origin」や「origin master」の意味が分かるようにするので適切にコマンドを使えるようになる
- 例)
git fetch origin
とgit fetch origin/master
の意味が分かるようになる
- 例)
そもそもGitとは
皆で開発をするためにファイルを管理してくれるシステムです.
これを使うことで皆で分担して同時に開発することができます.
例えば,Webアプリの1画面に対して,Aさんが一部,Bさんが別の一部を開発する...のようなことができます.
https://git-scm.com/
更にはバージョン管理ができます.
例えばバージョン10をリリースしたら,致命的なエラーが見つかったので一旦前のバージョン9に戻したいとします.
この時Gitも何も使っていなかった場合,バージョン9のバックアップを残しておけば戻せます...が,残っていなかった場合バージョン9に戻すことができません.
ですがGitを使用していればコマンドでバージョン9に戻すことができます.
別途バックアップを取っておけば...なんてことになりにくいです.
https://www.atlassian.com/ja/git/tutorials/undoing-changes
リポジトリ
皆で開発するためのディレクトリやファイルを「リポジトリ」という名前で管理します.
リポジトリは大きく分けて「リモートリポジトリ」「ローカルリポジトリ」の2つあります.
リポジトリ | 内容 |
---|---|
リモートリポジトリ | 皆で共有するリポジトリ.サーバーにある |
ローカルリポジトリ | 各個人で作業するリポジトリ.自分のPCにある |
リモートリポジトリには名前が付けられますが,
デフォルトでは「origin」というリモート名で設定されます.
ブランチ
用途に合わせてリポジトリ内で枝分かれさせることができます.
この枝分かれがブランチです.
ここでは例としてmasterとdevelopmentを考えます.
※masterブランチはgitを使用するとデフォルトで作成されるブランチ
ブランチ | 内容 |
---|---|
master | システムの本体.リリース版.基本的に触らない |
development | 開発用.基本的にここを触る |
origin, origin/master, masterの違い
以上を踏まえて以下の例で考えてみます.
項目 | 設定 |
---|---|
リポジトリ | リモートリポジトリ(origin),ローカルリポジトリの2つ |
ブランチ | 各リポジトリにmaster,developmentの2つずつ |
この設定の場合,
リモートリポジトリ「origin」の「master」と「development」ブランチがあり,
ローカルリポジトリの「master」と「development」ブランチがある状態になります.
更に,ローカルリポジトリに「origin/master」と「origin/development」がある状態になります.
(後ほど説明します.)
origin/masterとは
上で急に登場したorigin/masterですが,
これはリモート追跡ブランチと言って,リモートリポジトリにあるブランチの状態をローカルで持って置くためのブランチです.
...と言われても何でこんなブランチがあるのか疑問なので,このブランチがあると何が嬉しいかを説明します.
まず,Aさんがローカルで「hoge.js」を編集していたとします.その間にBさんがローカルで「hoge.js」を編集し,リモートリポジトリに反映させたとします.
その後,Aさんが編集完了し,リモートリポジトリに反映させようとするとGitから怒られます.
「「hoge.js」のここ編集したみたいだけど,既にそこ編集されてますよ.」
「どっちが正解何ですか?正しい状態にしてからまた反映してください.」
...みたいな感じです.怖いですね...
そこでこう考えました.「リモートリポジトリに反映させる前に,今のリモートリポジトリの状況を確認しよう」と.
そうなると,リモートリポジトリの状況をダウンロードする必要があるのですが,Gitには2種類方法があります.
- リモートリポジトリの状況をそのままローカルに反映させる(pullと呼ばれています)
- リモートリポジトリの状況だけ取ってきて,ローカルに反映はさせない(fetchと呼ばれています)
このfetchで使うのがリモート追跡ブランチ(origin/master)です.
一旦リモートリポジトリの状況だけ確認させて欲しいなって時に使うブランチですね.
因みにこの例の状態でpullをすると,
問答無用でリモートリポジトリの状況をダウンロードしてローカルに反映させようとするとするので,
Gitから「hoge.js」いじってますけどこれどうしますか?何が正解ですか?のような事を言われます.
Git-リモートブランチ
git pullとgit fetchとgit mergeそれぞれの違い
つまるところ
下の表が本記事で知りたい事でした.
項目 | 説明 |
---|---|
origin | リモートリポジトリの事でした. |
origin/master | リモートリポジトリ「origin」のブランチ「master」の状態がどうなっているかを見るブランチでした |
master | ブランチの名前でした. |
因みにgit fetch origin
とgit fetch origin/master
の違いは以下の通りです。
コマンド | 意味 |
---|---|
ogit fetch origin | リモートリポジトリ「origin」の全ブランチの状況を取ってきて! |
git fetch origin/master | リモートリポジトリ「origin」のブランチ「master」の状況を取ってきて! |
参考文献