Photo by Taylor Barber on Unsplash

バージョン管理

われわれは一つのファイルを何度も修正することがある．

このファイルが大きかったり内容が複雑だったりする場合， 修正は常に「改善」であるとは限らず，「改悪」であるかもしれない． 修正作業そのもののミスにより，意図しない修正を施してしまうこともある． また，修正によって大事な情報を削除しないといけないというケースも存在するだろう．
こうしたとき，以前の状態のファイルを全てバックアップして保存しておけば， こうした問題は解決できる．
つまり，「ファイルのバージョン違い版を管理する」ことが適切に行えれば良いのだ．

こうした，ファイルのバージョン変更にまつわる情報を管理するツールを 「バージョン管理ソフト」と呼び，これらを使うと以下のようなことができる．

  バージョン管理を導入すると…
           ※ 管理用のデータ(ファイル)を保存しておけば

1. どんなに古いバージョンのファイルも取り出せる．
   
   
2. 元のファイルを消しても復活させることが可能．
   
   
3. ファイルにバージョン番号などの情報を自動で埋め込める．
   
   
4. 同時に複数の更新方針に従ってファイルを更新できる．バージョンの「枝分かれ」が出来るというやつだ.
   
   
5. 複数人や複数のマシンでお互いに矛盾する更新作業をするトラブルが無い(というか無くす)． 競合(conflict)の回避 もしくは 競合の解決 と呼ばれる機能¹で，実はかなり重要な機能だ．

RCS

本講義では，バージョン管理ソフトとして, まずは入門として RCS を学ぼう．

この RCS は個人ユーザが使うのに適しており，比較的使いやすく，かつ，unix の歴史上も由緒正しいものであり，最初に学ぶには最適である. また，単純な分だけ，単独のファイルを管理するには後述のものより適しているとも言える．
また，より進化したバージョン管理ソフトとして他に GIT, CVS やSubversion などがある． これらは複数の人間で同じファイルを扱う場合や，ネットワーク越しにファイル管理を統合したいという場合にも対応できる優れたツールであるが，その分，使い始めるにはやや敷居が高いかな． 逆に，ローカル環境で個人で使う分には逆に RCS とそう変わらないとも言える．

そこで，本講義では個人が単独でファイルをローカルに扱うケースで RCS を解説する． 複数の人間で編集するとかネットワーク越しに統合したいという場合は 今だと Git (CVS や Subversionでも良いが) がより適しているので，それらを使うのが良かろう．

RCS 参考資料

RCS は 1982 年には既に姿を見せていたバージョン管理ソフトであり， 古くからよく知られている． 概念はシンプルで，使うコマンドもそう複雑ではないが， 参考となる資料があればより理解も深まるだろう．

それぞれの学習環境での状況

今回用いる RCS のインストール状況は各環境で以下のような状態だ．
ちなみに，古い RCS では rcs -V とするとバージョン番号が表示され，
新しめの RCS では rcs --version とするとバージョン番号が表示される．

(上の表の補足) Ubuntu 22.04 に RCS をインストールする手順:
下記のように，普通に apt コマンドでインストールすれば新しい版 ver. 5.10.1 がインストールされるのでそうすれば良い．

1
2
3
4
5
6
7

sudo apt udate
sudo apt upgrade
sudo apt autoremove
#
# …できればいったんリブート (sudo reboot)後に以下のコマンドを…
#
sudo apt install rcs

  RCS を用いるのであれば，今回の授業実習のあとに

• 環境変数 TZ を JST-9 に
• 環境変数 RCSINIT を -zLT -x,v に

設定しておくと楽ができるぞ．
具体的には，たとえばシェルとして fish を使っている人は ~/.config/fish/config.fish に

1
2

set -x TZ JST-9
set -x RCSINIT "-zLT -x,v"

と書き足しておけば良い．

RCS の概念

RCS を理解するには，おおざっぱに言って バージョン， バージョン管理ファイル，チェックイン，チェックアウト，ロック という概念が分かれば良い． それらについて説明しよう．

RCS でのファイル管理，編集の流れ

RCS を個人一人で用いる時は，通常は上の図にあるように 「ロックつき」でチェックイン&チェックアウトしていればまず問題はないだろう(ちょっと邪道だが)．

流れをもう少し詳しく書くと，RCS では

1. 管理したいファイルを「バージョン管理ファイル」に チェックインする．
   バージョン管理ファイルは，初めてチェックインするときに自動的に作られる．
   
   
2. バージョン管理ファイルから，使いたいファイルを ロックつきでチェックアウト して取り出す．
   
   
3. ファイルを編集する．
   
   
4. 1. へ戻る．

という繰り返しで用いるのが普通である．
何か特別なことをしたい時だけ，別のことをすればよい．

  RCS で使うコマンドは実質的に一つだけ

実は，下で示す ci -l -zLT というコマンドだけ覚えておけばだいたいなんとかなる．

  実習
以下の手順に従い，rcs を試してみながら理解せよ.
なお、以下の手順は コマンドプロンプト, cygwin, (CentOS などの)端末エミュレータといった CUI での操作を想定している．

1．RCS の練習用に適当なディレクトリに移動する．

2．そのディレクトリの下に，バージョン管理ファイルを置く特別なディレクトリ RCS を作っておく．
具体的には、そのディレクトリで

1

mkdir RCS

とする.

3．次のような内容のサンプルファイルを，ファイル名 dummy.txt で作る．

1
2
3
4
5

Sample File
My name is hogehoge.
なんでもいいから書け．
$Id$
$Date$

なお、最後の2行だけは必ずそっくりに書き入れること．

4．初めてのチェックインを, 「ロック付きでチェックイン & チェックアウト」という動作で行ってみる．

具体的な操作としては

1

ci -l dummy.txt

とするだけでよい．

  ci -l は「チェックインした後，自動的にロック付きでチェックアウト」する便利なコマンドである．

さて，上記の作業を行うと，最初は次のようにメッセージが出る．

1
2
3
4

dummy.txt,v  <--  dummy.txt
enter description, terminated with single '.' or end of file:
NOTE: This is NOT the log message!
>>

この >> の部分に「このファイルの内容を記述せよ」と言われているので，後々のためにも(なるべく英語で？)きちんと記入する．

なお，記入し終わったら， . (ピリオド)のみの行 を記入すれば「記入終わり」となる．

記入が終わると，

1
2

initial revision: 1.1
done

という表示が出て，バージョン 1.1 という真新しいバージョンでこのファイルが登録されたことが分かる．

5．ディレクトリ RCS の中にバージョン管理ファイルができているか確認する．

操作としては

1

ls RCS

とすればよいだろう．

6．ci -l の自動チェックアウトがうまくいったかを確認する．

つまり，チェックアウトされたファイル dummy.txt が存在するか確認する． 操作としては

1

ls dummy.txt

とすればよいだろう．

7．チェックアウトされたファイルがどう変わったか見てみる．

これは

1

less dummy.txt

とすればよいだろう． どこがどう変わったかよく見てみよう．
また，時間がどう記述されているか，自分の腕時計などと比べてみよ．

8．サンプルファイルの中身の無難な場所を編集して変えてみよう.

実際は Emacs などのエディタを起動しての作業になる．
なお、$Id:…, $Date:… の部分はいじらないようにしよう．

9．そして、再びチェックイン & チェックアウトを行ってみる．

ただし今度は，-zLT という特別なオプションをつけて、

1

ci -l -zLT dummy.txt

としてみよう．

  -zLT は，「ローカル時間を用いて時間表示を記述する」というオプションである． われわれの場合、「日本時間」で時間が表示される．

こうすると，

1
2
3
4

RCS/dummy.txt,v  <--  dummy.txt
new revision: 1.2; previous revision: 1.1
enter log message, terminated with single '.' or end of file:
>>

という表示が出るだろう．

ここでは 「このファイルをどう変更したか記述せよ」と言われているので， 後々のためにもこれも(なるべく英語で？)きちんと記入する．

なお，記入し終わったら，やはり . (ピリオド)のみの行 を記入すれば「記入終わり」となる．

今度の終了は単に

1

done

と表示されるだけだろう．

10．チェックアウトされたファイルがどう変わったか再び見てみる．

1

less dummy.txt

とすればよいだろう． どこがどう変わったかよく見ておこう．
とくに時間の記述がどう変わったか，よく比べてみよう．

11．dummy.txt を消去してみる!

バージョン管理のありがたさを実感するための作業の一つとして、対象ファイルを一回消してみよう．

1

rm dummy.txt

としてみれば良いだろう．

12．dummy.txt を復活!

上の作業で、情報の詰まったバージョン管理ファイルは消えていないので， そこからチェックアウトすればファイルを復活できる． やってみよう．

具体的には，

1

co -l -zLT dummy.txt

とすればよい．

  チェックアウトコマンド co は(特に指定しなければ)最新バージョンのファイルを取り出す．

13．最新バージョンのファイルと、古いバージョンのファイルの違いを調べてみよう．

それには、具体的には

1

rcsdiff -zLT -r1.1 dummy.txt

とすればよい． これは，「今ある dummy.txt とそのバージョン 1.1 の内容を比べよ」というコマンドになる．

14．これまで dummy.txt に加えた編集の履歴を見る．

具体的には，

1

rlog -zLT dummy.txt

とすればよい． こうすると，今までのチェックインの際に記述した変更内容などがリストアップされる．

15．dummy.txt に埋め込んであるキーワード(Id, Date)を取り出してみる．

具体的には，

1

ident dummy.txt

とすればよい． こうすると，$Id:… や $Date:… と書き込んだ部分が出力される．

  この機能はバイナリファイルに対しても有効であるので，本格的なプログラミングにも適用できる．
例えば，バイナリであるコマンド rcs 自身にはどのようなキーワードが埋め込まれているのか、調べてみよう．

RCS: キーワードの埋め込み

上にも出てきたように， $Id$ や $Date$ のように、ファイルのなかに決まったキーワードを $ で囲んで埋め込んでおくことで， RCS の様々な情報を自動的に記述することができる． 以下に，どのようなキーワードがあるのかを示そう．

  実習
上のキーワードを全て書き込んだファイルを作成し，チェックイン & チェックアウトして，キーワードがどう作用しているか確認せよ.

RCS の コマンド

以下に，RCS のコマンドについて簡単な一覧を載せよう． 通常はこれぐらい知っていれば十分なはずである(詳しくは man コマンドで調べれば良い)．

Git

次に，やはりローカルで個人で使うという同じ想定のもとで，バージョン管理ソフトとして現在，おそらくベストなソフトウェアの筆頭であろう Git について学ぼう． この想定下であれば行うことはほぼ同じだが，大きな違いが一つあってそれは

  Git は，基本的にはディレクトリ丸ごとを管理対象とする

という点だ． であるのでそのつもりで以下の内容を学ぼう．

  なお，Git は GitHub と呼ばれるサーバなどを用いてネットワークを使ってファイルを管理できる機能が特に優れているソフトなのだ． であるので，実際に使い込むのであればそうしたサーバとの連携について調べて使おう． ただし，阪大情報教育計算機システムのネットワークは Git の外部との通信を遮断するので他の環境で使おう．

さて，資料が少し長くなりすぎたので，簡単に紹介しておこう．

それぞれの学習環境での状況

今回用いる git のインストール状況は各環境で以下のような状態だ．

  CentOS 7 で git を update するには今現在だと以下のようにすれば良い．

sudo yum remove git
sudo yum install https://repo.ius.io/ius-release-el7.rpm https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
sudo yum install pcre2 (念の為．おそらく皆は不要だろう)
sudo yum install git --enablerepo=ius --disablerepo=base,epel,extras,updates

  Ubuntu 22.04 で(万が一) git が入っていない場合にインストールするには以下のようにすれば良い．

sudo apt update
sudo apt upgrade
reboot (念の為)
sudo apt install git

  Git を一回も使ったことがない場合は設定が必要になるだろう． とりあえず，以下の 2つのコマンドを実行しておこう．
なお，GitHub と連携させる場合はそちらで先に設定してそれを手元にコピーしてくる格好なので，下の2行の操作は不要だ．

git config --global user.email "namae@mailaddress.ac.jp"  ← 自分のメールアドレス
git config --global user.name "Taro Yamada"  ← 自分の名前

なお，git の設定については，git config -l とすると設定が出力されるので，上の設定を行った場合はその後に確かめておこう．なにも設定してないときはなにも出力されない．

Git の概念

(ローカルで使う場合) Git を理解するには，おおざっぱに言って リポジトリ，ステージング，コミット という概念が分かれば良い． それらについて説明しよう．

Git でのファイル管理，編集の流れ

Git を個人一人でローカルで用いる時は，通常は上の図にあるように ステージングとコミットだけしていればまず問題はないだろう(ちょっと邪道だが)．

流れをもう少し詳しく書くと，RCS では

1. ファイルやリポジトリを他からコピーしてきた場合でなければ， 最初に対象ディレクトリで git init というコマンドでリポジトリを作成する． これは一回だけやれば良い．
   
   
2. 管理したいファイルをリポジトリに ステージング & コミットする．
   git add と git commit を使う．
   
   
3. ファイルを編集する．
   
   
4. 2. へ戻る．

という繰り返しで用いるのが普通である．
何か特別なことをしたい時だけ，別のことをすればよい．

  Git で使うコマンドは通常はこれだけ

実は，下で示す
git add *
git commit -m "メッセージ"
git tag -a "タグ名" -m "メッセージ"
というコマンドだけ覚えておけばだいたいなんとかなる．

  実習
以下の手順に従い，Git を試してみながら理解せよ.
なお、以下の手順は コマンドプロンプト, cygwin, (CentOS などの)端末エミュレータといった CUI での操作を想定している．

1. Git の練習用に適当なディレクトリに移動する．
   
   
2. そのディレクトリに以下のようにしてリポジトリを作成する．

1

git init

3. 次のような内容(実はなんでもいい)のサンプルファイルを，ファイル名 dummy.txt で作る．

1
2
3

Sample File
My name is hogehoge.
なんでもいいから書け．

4. 以下のようにしてステージング & コミットをする．

1
2

git add *
git commit -m "なにかメッセージを書く"

5. サンプルファイル dummy.txt の中身を編集して変えてみる．後のためにわかりやすく変えておくと良い．
   
   
6. 以下のように，再びステージング & コミットをする．

1
2

git add *
git commit -m "なにかメッセージを書く"

7. 異なる内容(実はなんでもいい)で，他のサンプルファイルをファイル名 dummy2.txt などで作る．

1
2

Sample File No.2.
なんでもいいから書いたよ．

8. 以下のように，再びステージング & コミットをする．

1
2

git add *
git commit -m "なにかメッセージを書く"

9. これまでの情報の登録がどうなっているか，次のようにして記録を見てみる． これまでのファイルの追加や変更などが記録されているのがわかるだろう．

1

git log -p

10. Git にはバージョンという概念がなく，代わりにハッシュ値と呼ばれる長ーい文字列(git log で "commit" のあとに表示されているやつ)が用いられる． ただこれは見てわかりやすいものではないので，わかりやすくするために重要なコミットには「タグ」をつけることがオススメだ． それには git tag -a "タグ名" -m "メッセージ" とする(最後のコミットにタグをつける)．
    ここでは例として以下のようにやってみよう．

1

git tag -a "v1.1" -m "I tagged a version number."

11. タグがどうなったか，以下のように確認してみよう．

1
2

git log
git show v1.1

12. サンプルファイル dummy2.txt の中身を編集して変えてみる．後のためにわかりやすく変えておくと良い．
    
    
13. 以下のように，再びステージング & コミット & タグづけ をする．

1
2
3

git add *
git commit -m "なにかメッセージを書く"
git tag -a "v1.2" -m "I changed the dummy2.txt."

14. タグがどうなったか，さらに確認してみよう．

1
2

git log
git show v1.2

15. 古いファイルを取り出してみよう． それには git checkout コミット指定(ハッシュ値やブランチ，タグで) -- ファイル名 とすれば良い． ここでは例えば以下のようにやってみよう．

1

git checkout v1.1 -- dummy2.txt

そして， dummy2.txt の中身が古いものに戻ったことを確かめておこう．

レポート

以下の課題について能う限り賢明な調査と考察を行い，
2022-AppliedMath7-Report-11
という題名をつけて e-mail にて教官宛にレポートとして提出せよ. なお，レポートを e-mail の代わりに TeX で作成した書面にて提出してもよい.

  注意
　　近年はセキュリティ上の懸念から，実行形式のプログラムなどをメールに添付するとそのメールそのものの受信を受信側サーバが拒絶したりする． そういうことを避けるため，レポートをメールで提出するときは添付ファイルにそういった懸念のあるファイルが無いようにしよう．

課題

1. この授業でこれまでに作成したファイルの全てに RCS もしくは Git でのバージョン管理を試みてみよ．
   
   (RCS の場合)その際，$Log$ を盛り込んでみて支障がないかどうかチェックせよ． もし支障があるならば，どうやって解決すれば良いかマニュアルを調べるなどして考えよ．
   
   
2. RCS や Git の GUI(グラフィカルユーザーインターフェース)版というべきソフトウェアが無いか探してみよ． 見つけたならば，使ってみてレビューせよ．
   
   
3. Git における「競合(conflict)の解決」がどのようなものか，調べてみよう．
   
   
4. Emacs や Visual Studio などのエディタは RCS や Git などのソフトを使ってバージョンコントロールが出来る． Emacs 使いは，C-x v v だけ知っていればだいたい使えるし，Visual Studio には Git メニューが有るはずだ．試してみよう．
   ※ Emacs では RCS の名称は「大文字での RCS」だ．rcs は認識されないので気をつけよう．
   
   
5. 余裕があるならば，GitHub に登録して，たとえばシェルの設定ファイルなどを試しに管理してみよう．