Remote Repositories (続き)
Developing in Your Repository
-
masterにpushすると、origin/masterよりも1つ進んだ状態になるよ、という話
- リモート追跡ブランチにはコミットは追加されない
Pushing Your Changes
-
論理的な流れ
- ローカルブランチの変更を
git push
でリモートブランチに反映 - リモートブランチの更新がリモート追跡ブランチに反映される
- ローカルブランチの変更を
- 実際にはround-tripはない
Adding a New Developer
- 「正式な」リポジトリを1つ用意したなら、それをcloneするだけ
- デフォルトのremote、
origin
が設定される
Getting Repository Updates
- git pullでリモートの変更を取り込む
git pull options repository refspecs
-
git pullは git fetch + git mergeまたはrebase
- デフォルト前者
- git pushの反対はgit pullではなくgit fetch
The fetch step
- repository省略時はremote
origin
が指定されたものとして動作 - remoteのGit URLはconfigファイルで定義されている
-
refspecs省略時は、configファイルの全
fetch =
行が指定されたものとして動作- デフォルトconfigだと、
+refs/heads/*:refs/remotes/origin/*
- ごく一部のブランチしか要らない場合は適宜
fetch =
行を書こうね
- デフォルトconfigだと、
From /tmp/Depot/public_html
3958f68..55c15c8 master -> origin/master
- 3958f68..55c15c8をリモートリポジトリ
/tmp/Depot/public_html
のmaster
からローカルのorigin/master
に持ってきたよ、の意
The merge or rebase step
configの一節
[branch "master"]
remote = origin
merge = refs/heads/master
pushRemote = origin
rebase = true
-
意味
- masterがカレントブランチの場合、
- fetchのデフォルトのremoteは
origin
で、 - git pull中のマージフェーズではrefs/heads/masterを使い、
- pushのデフォルトのremoteは
origin
- デフォルトで
--rebase
指定
- git fetch単体で使用する場合はコマンドラインでリモート追跡ブランチを指定する
Should you merge or rebase?
- どうぞ好きな方を
-
マージ
- pullするたびにマージコミットが生じうる
-
議論の的
- 歴史が散らかってしまうからやめろ派
- 正しい歴史だから残せ派
-
リベース
- マージと比べて歴史は簡潔になる
- コミットグラフ上、そのトピックに実際よりも遅く着手したように見える
-
どちらにせよ、最終的に生じるコミットは元のどのコミットとも異なることに留意せよ
- テスト通らないかも
-
著者はシンプルで直線的な歴史が好みなのでrebase派
- コミットの前後関係が変わってしまうことはあまり気にしない
Remote Repository Development Cycle in Pictures
Cloning a Repository
Alternate Histories
- divergeの話
origin
A-B-C-D
yours
A-B-X-Y
- Bで歴史がdivergeしている
- どちらかの歴史がより「正しい」ということはないことに留意する
- mergeで解決
Non-Fast-Forward Pushes
origin
A-B
yours
A-B-X-Y
-
この状態なら、コミットX,Yは簡単にpushできる
- Fast-Forward
- 特別なマージ(縮退マージ)の一種
- originも別の歴史を刻んでいる場合、そうはいかない
origin
A-B-C-D
yours
A-B-X-Y
- non-fast-forward push problem
-
pushを試みてもrejectされる
-f
で後勝ちできなくはない
Fetching the Alternate History
origin
A-B-C-D master
yours
C-D origin/master
/
A-B-X-Y master
- fetchでリモート追跡ブランチを最新に
Merging Histories
origin
A-B-C-D master
yours
C-D origin/master
/ \
A-B-X-Y-M master
Merge Conflicts
- コンフリクトしたら適宜マージして
Pushing a Merged History
- リモートの変更を取り込みたいだけならさっきので終わり
-
リモートにローカルの変更を反映したいならpushする
- fast-forward
origin
C-D
/ \
A-B-X-Y-M master
yours
C-D origin/master
/ \
A-B-X-Y-M master
Remote Configuration
- Git URLやrefspecをいちいちタイピングしてられない
-
コンフィグを設定する3つの方法
- 究極的には結局
.git/config
ファイルを編集している
- 究極的には結局
Using git remote
- リモートリポジトリ絡み専用のインタフェース
- git remote add とかそういうの
Using git config
- コンフィグ一般
- リモートリポジトリ関連含む
Using Manual Editing
- git remoteやらgit configやらのコマンドと格闘するより、慣れ親しんだエディタで直接編集したほうが早い事も
- 上級者向け
column: Multiple Remote Repositories
git remote add
を複数回実行することで、remoteを複数登録できる- 【補】herokuのデプロイとか
Working with Tracking Branches
Creating Tracking Branches
-
git branch --track
とかでリモート追跡ブランチを自分で作れる話- v1.6.6より前は自分で作らないといけなかったらしい
- たぶん無縁なので略
Ahead and Behind
origin
A-B-C-D master
yours
C-D origin/master
/
A-B master
- これとかは「Your branch is behind ‘origin/master by 2 commits, and can be fast-forwarded.」
Adding and Deleting Remote Branches
- pushするまでローカルブランチの追加をリモートは知る由もない
- 同様に、ローカルブランチの削除をリモートは知る由もない
- リモートブランチの追加・削除はすべて
git push
で行う - 以下すべて同じ意味
git push upstream new_dev
git push upstream new_dev:new_dev
git push upstream new_dev:refs/heads/new_dev
-
普段指定しているのはrefspec指定のショートハンドに過ぎない
- 「ローカルの
new_dev
をリモートのrefs/heads/new_dev
にpush」の意
- 「ローカルの
- source(ローカル)を空にすることで削除を意味する
git push origin :foo
git push origin :foo
To github.com:wand2016/org.git
- [deleted] foo
- 心臓に悪いのでこう書ける
git push origin --delete foo
git push origin -d foo
Bare Repositories and git push
-
Gitは対称的
- どのリポジトリも特別ではない
-
とはいえ、non-bareリポジトリ = developリポジトリにpushすることもできるが、やめておけという話
- developリポジトリで作業中に、いつの間にかpushされてHEADが変わる可能性がある
- 制限ではない。ベストプラクティス
英語
-
assimilate
- 同化する、消化する
-
equal stature
-
同じ身長
- いずれも特別ではない、の意か
-