Git/GitHubを独習してきたので、ここらで「正常系」についてまとめようとおもった。

背景とねらい

Git/GitHubを（いまさらながら）独習してきて、理解を進めるために、「正常系」についてまとめようとおもった。

正常系については「システム設計の法則（正常系と異常系についての一般論）」にて。

• Git/GitHubの「正常系」を整理
• OSS開発の「作法」で「わからないところ」を特定

ができればとおもう。

Git/GitHubの基本ユニット

全体を通じて、Git/GitHubの構成は、この基本ユニットが念頭にあるとおもわれる。「ようするにぜんぶ、コレの応用／組み合わせだ！！」と念じれば、頭がスッキリする（とおもう）。

以下、簡略化のために「→」の「commit」は省略する。

localのみで運用する場合

もっとも単純な、localのみで運用する場合は、こうなる。ローカルのみで運用するメリットは少ないので、実際にこれだけで使うことはないだろうけれど。

remoteとlocalで運用する場合

remoteとlocalで運用する場合も、図にすると同じかたちをしている。

慣習として、remoteはoriginと名付けられる。remoteからlocalにcloneしたとき、特に指定しなければoriginと呼ばれることになる。

初回のクローンは
$ git clone [e-mail]:boo/foo.git

２回目以降のプルは
$ git pull origin master

編集後にプッシュするのは
$ git push -u origin masterとしておくと次回から
$ git pushで済むようになる。

remoteとlocalで運用し、ブランチがある場合

localでbranchを作成する場合は、これまでの2階層が3階層になるだけで、かたちは同じである。

branch作成は

$ git checkout master

としてmasterに移動したのち、

$ git branch <branch name> // branchを作成
$ git checkout <branch name> // branchに移動

もしくはこのふたつをあわせて行うコマンド、

$ git checkout -b <branch name> // branchを作成し、そこに移動

上図には示していないが、remote(origin)にブランチをプッシュするのは
$ git push -u origin <branch name>

• !? このとき、remote(origin)でも、masterではなく、に分岐し、そこにpushされるということでいいのかな？　⇒　Yes、そのとおり。branchをpushして、origin/masterに入ってしまうことはない。

• 図も、remote(master/branch) - local(master/branch)としたほうが議論の見通しがいいのかもしれない。今後の修正余地ということで。

OSS開発の場合

OSS(open source software)開発では、下記手順が推奨されている。

1. 開発元のリポジトリから、自分のremoteリポジトリにfork（GitHub to GitHub）
2. 自分のremoteリポジトリをlocalにclone（GitHub to myPC）
3. localのcloneから修正branchを作成し、そこで修正
4. localの修正branchから自分のremoteのbranchにpush（myPC to GitHub）
5. 自分のremoteのbranchから開発元のリポジトリにpull request（GitHub to GitHub）
6. 開発元のリポジトリでmergeされる

実戦上は、プルリク後の修正どうするか、コンフリクトどうするか、開発元でコミットが進んだものをどう取り込むか、などいろいろあるが、正常系に絞ると上記の通り。

upstream（開発元をこう名付けることが多い様子） - remote - localの３階層、それぞれにブランチがあるので６階層（upstreamのブランチを無視するとして５階層）になるが、あくまでも基本形の組み合わせにすぎない。

コマンド的にも、新規コマンドはない。「プルリクエストを送るとき、GitHub上で行う」が、これまでになかった追加操作。

OSS開発でわからないこと

１回目のプルリクまでは載っているのだけれど、プルリクが通ったあとどうすればいいか（２回目はどうすればいいか）、あまり見つけられないんだなあ（探し方が悪いのだとおもうけど）。図のふたつの青い｛がわからなくて。

１）プルリクが通ったあと

• localでは修正branchを、masterにmergeするのでいいのか？
• remoteでも修正branchを、masterにmergeするのでいいのか？

　⇒　これらは行わず、次の２）にいけばいいのだろうか？

２）つづいて次のバージョンの修正を行う場合は

• upstreamからlocalにpullし、localからremoteにpushする、でいいのか？

これでよければ、１回目と同じプロセスに入るので、問題はないのかなとおもう。まさか、もういちどforkからせよ、とは言わないだろうし……。

理解がすすんだこと

上で「わからない」と書いたこと、わかった（気がする）。よりシンプルなので、正しいはず。

• ｝Aのところでは、なにもしなくていい！
• ｝Bのときには、upstreamからlocalにpull、localからremote（GitHub）にpush。

スッキリ！

参考サイト

【試行】GitHubでforkしたり、Issueドリブンやってみる
https://qiita.com/sky0621/items/9811e874edd507a068a4
　⇒　ひと手順ずつ、コマンドと結果がのっていて、たいへん助かる！
　　　fetch〜rebase〜squashあたりも細かく載っている！

Github で Fork してから Pull Request をするまでの流れ
http://kik.xii.jp/archives/179
　⇒　こちらも、図式化されていて、コマンドも丁寧に書いてくださっているので助かる！
　　　pull〜rebaseあたりも細かく（squashはない）