コーディングって、流れる水のように計画通りに進むことはあまりないから、ソース管理はとっても大切だよね。作業していると、あるモジュールが終わらないうちに他の機能を触ることもあるし、急に新しいアイデアが浮かんで、今までやっていたことを全部ひっくり返してもう一度コードを書くこともあるんだ。コーディングはまるで文章を書くことに似ていて、『書いて』『修正して』『また書いて』の繰り返しだからね。
唐の詩人、賈島が『鳥は木の上で眠り、僧は月明かりの下で門を押す』という句を書いて、『押す』か『叩く』かどちらの表現を使うか悩んだことから『推敲』という言葉が生まれたんだ。個人的には悩むことなく『押す』を選ぶけど、賈島の悩みを聞いた韓愈（唐を代表する文人）は『叩く』を勧めたって…それが重要ではないけど、いずれにせよコードを書くときも同じように膨大な（論理的な）推敲をすることになるんだ。
そんな理由でコーディングをするとき、ある段階で『ここで一旦スナップショットを作っておこうかな』って感じたら、その瞬間を保存しておくといいよね？その後、他の作業をしていて気に入らなかったら、そのスナップショットからやり直せるんだ。そういう作業を、形状管理やバージョン管理と呼ぶんだよ。そのツールの中で、既存のSVNをほぼ置き換えたのがGitなんだ。Gitの最大の特徴はソースを分散型で管理できることだよ。
まずはGitの構造について知ろう。開発者が使うローカルマシンに保存されている現在の作業中の物理的なソースが保存されている場所、それがWorking Directoryなんだ。エクスプローラーやファインダーで見たときに実際にファイルが存在する場所だね。開発ツールで保存するとこの場所に保存されるよ。形状管理システムを使っていなければ、この場所だけが存在するんだ。Working Directoryでは保存作業をすると前のバージョンは消えてしまう。でも、ここにGitを適用すると、ローカルにはStaging AreaとLocal Git Repositoryの領域ができて、スナップショットはLocal Git Repositoryに保存されるんだ。この作業をCommitと言うんだ。そして、また特定の時点のソースに戻りたくなったら、このLocal Git Repositoryからその時点のスナップショットを取り出すんだ。この作業をcheck outと言うよ。途中に存在するStaging Areaは、Working Directoryで作業を進めているとき、まだcommitするほど完全ではないときに、一時的に作業内容を保存しておく場所なんだ。（コーディングツールによっては、このStaging Areaが明示的に見えない場合も多いよ）
ここで、一番右にあるのがRemote Git Repository、つまりリモートリポジトリだね。ここにアップロードしておけば、ノートパソコンが壊れてもまたソースを復元できるんだ。そして、単独開発ではなく、コラボレーション開発をするときにもこのリポジトリを通じて互いにソースを交換するんだ。Local RepositoryからこのRemote Repositoryにプッシュする作業をpushと言うんだ。逆にRemote Repositoryからソースを引っ張る作業をPullと言うよ。でも、pushの反対の作業は実はpullではなくfetchなんだ。fetchをするとLocal Git Repositoryまでソースを下ろすんだ。でも、通常Remoteからソースを持ってくるときは続けてコードを書く目的があるから、Working Directoryまでソースを下ろしてくれるpullをよく使うんだ。こうしたリモートリポジトリサービスを提供しているサイトが有名なGitHub(github.com)だよ。
さて、協力して作業するときを考えてみよう。このときは、ソースのマスターを管理する人を明確に指定しておくといいよね。共に開発するためには、まずはマスター（base repositoryと言う）からソースを取ってこなきゃいけないんだ。この作業はリモートサーバーRemote Repository間で行われ、これをforkと言うんだ。このとき、そのbranchの最後のcommitされたバージョンを持ってくることになるんだ。これをheadと言うんだ。（正確にはheadとはそのbranchの最後のコミットに対するポインターのことを指すんだ）
その後は上記の個人作業と同じだよ。forkしてきたバージョンをWorking Directoryまで引っ張ってきて、その上に自分に割り当てられた作業を行うんだ。その作業が終わったら、自分のRemoteにPushしてアップロードし、ソースをforkしてきたサーバー側にpull requestを送るんだ。すると、マスター管理者はそのソースに問題がないか、その後の作業部分とconflictがないかを確認した上で、これをbase repositoryにマージすることになるんだ。
内容は簡単に見えるけど、実際に協力して作業するときにはある程度のガイドラインを作っておいて、実際に進めながら最も適切な運営方法を見つける必要があるよ。forkやPull Requestを行うbaseのbranchもお互いに混乱しないように明確に定義する必要があるし、あまり頻繁にPull Requestをするのも避けたほうがいいよね。でも、やっぱり進行中のプロジェクトの特性や協力構造、そして開発者たちの能力によって毎回適切なガイドラインは異なるだろうね。🌟
大切なのはやっぱり口だけじゃなく、実際に回してみることだよね？😉
次回はxcodeを使って開発をする際、xcode内のSource Controlメニューを使って複数人で協力する方法について話してみようと思うんだ。📱
