ちなみにGW中bitbucketとずっと戯れていたわけじゃないよ。猫と戯れていただけだよ(´；ω；｀)
bitbucket は自分のリポジトリをforkできます。
→確か前々回ぐらいの #TokyoMercurial で @troter さんがそんなことを呟いていましたが、確かにできましたｗ
githubはしらん。
まあ、普通しないよね。練習以外に何に使うのだろう…
あとpull request そのものについて詳しい訳じゃないので間違っている場合はご指摘ください。
名前からして「ねー、ねー。僕のリポジトリ（ブランチ）pullしてよ〜」なんですよね。
準備
とりあえず適当にリポジトリを作ります
作ったらテキトーにコミットしてpushしておきます
bitbucketに戻ってforkしてみます
普通他の人からforkするときはリポジトリ名はそのままでしょうけど、自分で自分のリポジトリをforkするので名前は変えたほうがいいと思います。
fork結果を見るとこんな感じで、何をforkしたのかという情報とかがオリジナルと違う点のようです。
compare fork というのを選ぶと、hg in/out を実行した結果が見られます。
作ったばっかりなので当然差分はありません。
とりあえずdefaultブランチのままぶん投げてみる
forkした側を適当に修正して、pull requestをしてみます
自分のどのブランチを相手のどのブランチに送り込むのか選択する感じ？
compare forkを見てみたところ
さっきと違ってoriginalとの差分がわかります
pull requestを受け取った側
とりあえず受け入れてみる
フツーにpullした状態が出来ます。
調子に乗って2個コミットした状態でRequestを投げてみます
compare fork だと hg diff -r b68e677f670d とやったような感じ
（2個分まとめての差分）
受け入れた結果。
何も問題なさそうです。
拒否ってみる（拒否られてみる）
テキトーにコミットしてpull Requestしてそれを拒否ってみました
Rejectボタンを押すとこんな画面で、拒否理由を書いてRejectするようです
拒否完了
じゃあ、肝心の拒否られた側ですが…
どうやらInboxにメールが届いているだけで、視覚的にダメだったお！みたいなのはなさそうです。
まあ受け入れられたときもそんな感じですが。
俺が気がついていないだけでもっと視覚的な何かがあるんでしょうか？
ところで拒否られたらどうすればいいんでしょう？
個人的にはstripしてなかったことにしてしまえばいいかと。
もしくは再度forkすればいいんじゃね？
backoutがいいんじゃね？的なこと書いてありますが、forkしたリポジトリが複数人でガンガンコミットしたり…
ってことは無いでしょうし。わかんないけど。
あとこの作業後にbackupファイルがDL出来るみたいです。
ローカル側はまあ適当に直せますしね。
下図みたいにpull requestしようとしたら元側が更新されていた…みたいな場合
まあrebaseしろって話でしょうけど、やってみる
受け入れ側…よく見たら「Accept and merge」になっている…
ということはマージして受け入れるんだろうなぁ
押してみたらコミットメッセージが書けるようになっていた
結果 まあ当然の結果
pull requestを受け入れてもらったわけですが、当然下記のように元リポジトリとfork側で違う歴史になりました
揃えないといけませんがどーしましょう
別にfork側のリポジトリを消して再度forkしてもいいと思いますが、改めてcompareを見てみるとコマンド書いてます。
ので、このまま実行してみます。
cd fork_repo_path hg pull -r default ssh://[email protected]/orginal/orginal_repo hg update default
hg serve でローカルの状態見てみるとこんな感じになる。
これでfork側がoriginal側を追従できた
あとはpushしてやればOK
ていうかpull requestを取り込むかどうか、ローカルで確認したいんですけど！という受け入れ側(original側)はどうすれば？
というのも実質さっきのやつと一緒
forkした側で見れるcompareのoutgoingに書いてある通りに実行でいいんじゃね
# オリジナル側 forkした側じゃないよ cd orignal_repo_path hg pull -r default ssh://[email protected]/fork/fork_repo
上記みたいにpull requestしてきた人のデータを直接pullすればローカルでじっくり確認できます。
ちなみにこのrequest結果をローカルでみて、
「いけるいける！！」
と思いオリジナル側がこのままpushしたらどうなるのか…
なんと、受け入れた事になりました！
ちゃんと受け入れたよ！ってメッセージも発行しているし、さすが。
正直ここまで来たらもう先は読めたしやらんでもいい気がするけど、ブランチ切ってpull request も試してみる。
一応下記を試す
すべてRequest側はhogeブランチを切るとして
- hogeブランチをdefaultに取り込んでもらえるかどうか
- hogeブランチをhogeブランチとして取り込んでもらえるかどうか
というわけで一つ目。
まあこんな感じでsend requestを投げた
requestを投げた側なんだけど、compare forkに差分表示が無い…
なにかしら表示してくれると思ったんだけど、もしかしてdefault ブランチのみを追従しているのかな？
（だからcompare に表示されるコマンドが -r オプションつけているかも…？）
受け入れる側も差分とかは出るものの、ブランチ切られているってことは
ローカルで確認しようとした時にヤヤコシイよね。
ブランチ名指定しなかったら下手したら腐るほどデータ引っ張ってきちゃうし。
まあとりあえず受け入れて…と思ったら、これはAccept and pull なのか。へ～
っておい、やっぱりマージじゃねーかorz
でもまあpull request的に
「hogeブランチだけどdefaultに取り込んでね！」
って明示してんだから動作的には正しいですよね。
でもマージ時のコミットメッセージ書けなかった…
次、hogeブランチとして取り込んで！！！
フツーにpullして終わりました。めでたしめでたし
pull requestの内容が競合するようなものだったらどうなるのか
いやまあ正直requestする側がrebaseしてくれれば…ね… ってのもあると思うんですけど
pull requestと本家の更新が同時とかってこともあるだろうし、試さずにはいられない
compare forkを見る。もうおもいっきりコンフリクトって書いてある、赤字でｗ
それでも気にしないで送りつける
受け取った側。
コンフリクトしてるから取り込むなら自分で解消してねってところですかね。
送り手的にはcomapreで事前にコンフリクトがわかるわけですし、やっぱり解消した上で送ったほうがいいとは思います。
けどまあ送ることはできるということで。
競合した上にブランチ切ってあったらどうなるのか？
ブランチ切るとそれはcompareとして表示されなかったので、一見コンフリクトと見なされないのではないか？
（いやもちろんfork側がincomingを見て、差分があったら取り込んだ上でpushすればいいんだけど）
試してみると… なんだちゃんとコンフリクトって出ますね。
わたしoriginal側だけどforkした奴が素敵だから勝手に取り込みたいの！
pull request 出してくれているわけじゃないけど、いい修正だし欲しいなぁ…
みたいなとき
実際そんなパターンがあるのか？と思いますが、あったんですよこれが。
まあ、pull requestを取り込むかどうかローカルで確認したい時と同じでいいハズ
そして今更気がついたけど、コミットする人の名前変えればわかり易かった…
こんな状態で
cd original_repo_path hg pull -r default ssh://[email protected]/fork/fork_repo #取り込むか確認したら hg push
で、こうなる。
じゃあ開始時点がこんなだったらどうするか？
まあ諦めてマージな気がするなぁ
とりあえずpullして持ってきた状態
まずマージしてみる
至って普通
続いてrebaseなんだけど…そもそもこの場合ってrebaseは間違っている気がするんだなぁ…
なぜならpullして持ってきた状態って全部のphaseがpublicなので基本rebaseしない前提のはず…
まあでもやってみます
pullして持ってきた方を自分にくっつけることにした場合
cd original_repo_path hg phase -d -f tip hg rebase -d 9 -s tip hg push
結果
一直線になっているし問題なさそうだけど、リビジョン番号が変わってしまうことに注意
まあそれ自体は別にわかりきっていることですが…
それよりもfork側のcompare forkから incomingを見るとこうなる
もちろんoutgoingもある
うーん、びみょー
逆版（自分のcommitをpullして持ってきたcommitにつなげる）ってのはもっとやらない気がする。
だってoriginal側を変更するということはstripしないと見た目おかしくなるし、
何より見ている人、触っている人がそれなりに居るだろうからまずやらないよね？
なので省略
有りなのかどうなのかわかりませんが、マージはしたくないけど取り込みたいし…の場合
「やあやあ、そのコミット リベースした上でpull requestしてくれないか！」と連絡するのが一番よかったりして…
色々とやってみたけど結局どうpull requestするのがいいんだろう？
GitHub的にはこちらのブログを見ると（pull request マナー でググってtopだった）
pull request用のブランチ切ってrebaseしてまとめてそれを投げるのが良いらしい。なるほど。
じゃあbitbucketというかhgの場合は…
適当に幾つか見て回りましたが、ほぼ default -> default だったので
特段pull request用にブランチ等は意識しなくて良いようです。多分。
なので pull request 前にoriginal側との差分を最小限にして（取り込んでrebaseして）から
やればまあいいんじゃないかなぁ…
手順的には
- forkする
- 作業する
- original側をpullしてくる
- 更新があったらrebase
- push
- pull request
みたいな手順になるんでしょうね。きっと。
何れにしても自分で自分のリポジトリをforkできるんで色々と試しておくといいのかもしれません。
あとは実際にpull requestしてダメだったら駄目出ししてくれるはず（他力本願
ついでに言うと #TokyoMercurial に参加すると誰かがやさしく教えてくれるかもしれない？（ステマ
0 件のコメント:
コメントを投稿