ひとりで github で遊ぶ

Satoshi Nakagawa

1 はじめに

1.1 これまでの話

一人で git で遊ぶ と git でログをみる までにおいて 次のことを学びました

1.2 これからの話

「これまでの話」は、一言で言えば、 「あたかも github がないかの如き状況」での「話」でした。 ローカルな作業ディレクトリ （およびローカル・リポジトリ）で git をつかう話をしてたわけです。 これからは、もう一度リモート・リポジトリ、 すなわち github に蘇えってもらいます。

2 もう一つのローカル

さて、これまでのローカルな作業ディレクトリが あなたの職場にあるコンピューター（O とします）のものだとします。 「これからの話」では、 もう一つのコンピューター、 家にあるコンピューター (H とします) での作業が問題となります。

2.1 これまでのローカル（Ｏ）

Ｏでの作業がひと段落したら、 (1) まず作業していたブランチを main ブランチ（「幹」ですね）にマージします。 （cherry-picking するのが理想ですが、それは後日。） この時点で、ローカルリポジトリと （GitHub にある）リモートリポジトリとは食い違っています。 ローカルリポジトリのほうが少し先に進んでいるわけです。

  1. 今日の結果である、 できあがったローカルリポジトリを、 リモート・リポジトリに押しこみます。1
git push

リモートリポジトリの状態が、 Ｏのローカルリポジトリと同じになりました。

これでＯでの作業は終了です。 片付けをして帰りましょう。

2.2 あたらしいローカル（Ｈ）

さて、家に帰ってゆっくりする前に きょうの職場での作業でいくつか気になる点、 修正すべき点、 書き足す点があるとしましょう。 家でさきほどの作業の続きをします。

家ですでにこのプロジェクトの作業をしていたならば、 作業用ディレクトリはできていたでしょうので、 そのディレクトリ (naturalism/) に移動します。 そして git pull して、 新しい変更点（職場でおこなった変更点）をとりこみます。

家でこのプロジェクトをするのが初めてならば、 git clone をして、 家のコンピューター（Ｈ）に作業ディレクトリを 作成します。

2.3 あっちこっち

家でもできればブランチを切るのがいいでしょう。

いまのところ、 ブランチはローカルに限定されています。 家の作業ディレクトリから 職場の作業ディレクトリでつくったブランチにアクセスはできません。 ブランチをグローバルにする仕方は後日述べます。

Ｈでも test というブランチを切ることとします — git branch test。

このブランチで作業して、 add して commit （そしてメッセージを付加）します。 何度もいいますが、 「add の意味がない」 — 「add して commit するより commit だけでいいじゃん」 と思われるかもしれませんが、 ここは穏便に・オンビンに。 いうとおりにしてください。

そして、 作業がおわったら、 「幹」 (main ブランチ)にもどって、 test ブランチをマージしてください （もちろん cherry-picking ができるのが理想ですが、 それは後日・・・）。

git checkout main
git merge test

もし複数メンバーで作業をしているなら、 git pull して、他の人が push した変更をとりこみます そして、最後に git push して、 自分の変更部分を、 github にあるリモート・リポジトリに押し込んで、 github を最新状況にします。

翌日、職場にでかけ、 まず (1) ローカルリポジトリを最新の状況にします — git pull。 そして (2) 作業をはじめます。

さいごに作業結果を git push してください。

その翌日・・・

3 けつろん

というわけです。

これでとりあえず GitHub での仕事が可能だと思います。

まだ書いていないのは (a) add と commit の取り扱い、 とりわけ「心変わり」があったときのやり方、 (b) ブランチからいい所取りする cherry-pick のやり方、 そして、 (c) pull したときに起こる可能性のある、 他の作業ディレクトリでの変更（あるいは他の人の変更）との 食い違いの修正の仕方です。

これらについては、後日述べます。

とにかく、こらまでの知識で git/github を使っての 論文執筆は可能になったと思いますので、 はじめてください。

  1. もし複数のメンバーが参加するプロジェクトならば、 まず git pull して、他のメンバーの作業をとりこむことになりますが、 それはまた後日に述べます。↩