リーナストーバルス氏がGitで本当に目指した大事なものの勘所(4/6)


その3から続き

確認の方法:ステージングの重要性

本人は明文化していませんが、以下の様な幾つかの点を気にしながら作業していたと思います。

  • マージするときは、誰かが全体を認識して判断する。
  • 正しく動くかどうか、確認もする。(動かない時は、苦労して戻していた)
  • そもそものプログラムの意図や方針を理解してそれを曲げたり外れたりしない。
  • 正しく既存のプログラムと連携する。

開発者であればわかると思いますが、優先度というものを理解し、それを軸にプログラムは動いています。(ポリシーみたいなもの)

また前後のプログラムと整合していること(データの扱いや、状態遷移、取りうる値、全体の振る舞い)がとても重要です。

ソーシャル化するOSS開発者たち - @IT
http://www.atmarkit.co.jp/news/analysis/200904/14/git.html
Gitはマージしたときに、デフォルトで、どこに何行の変更が加えられたかなどの統計情報を表示する。そのために、ソースコード全体を走査する。これは比較的重たい処理で、規模が大きいと1、2秒かかるという。しかし、このデフォルトの機能をオフにすることをリーナスは勧めない。「彼らのことは信じていますよ、でも、クスリ飲むのをやめたかもしれないじゃないですか。正直に言いましょう、昨日彼はオッケーなヤツだったかもしれないけど、今日はそうじゃないかもしれないよね」。だから、信頼している開発者から取り寄せたパッチの適用であっても、それによってどういう変更があったかを毎回確実に確認できることは重要だという。だから、差分が1秒で取れるか30秒かかるかというパフォーマンスの違いはクリティカルで、それは開発スタイルを変える重要な要素であるのだ、という。

おそらく、リーナス氏は、わかっているのかの一言に大抵済まされていますが、こういうことをわかっている人であれば、日本人であれ認められると思います。(概念を理解し、正しくプログラムレベルでも実現すること)

(まあ、リーナス氏は、C言語でOSまでも書いているので、かなりアーキテクチャレベルでしっかり過不足なくプログラムが組まれていることを望んでもいます。たぶん)

ソーシャル化するOSS開発者たち - @IT
http://www.atmarkit.co.jp/news/analysis/200904/14/git.html
2週間にわたって同じサンドボックスで開発していたとしたら、ほかの人が加えた変更が見えない。このため、マージのときにコンフリクトが発生して、その解決に時間がかかる。  「svnでブランチをマージするときには、1週間前から計画するもんです。これはひどすぎる」  分散ソースコード管理システムでは、各人が自分のレポジトリを管理しているため、互いに他人が作成したパッチを常に取り込んでいくことができる。何かコンフリクトがあっても、問題が小さい間に、そのコードに詳しい開発者が問題を解決できる

話を少し戻しすと、確認のために使いやすくする重要なポイントがいくつかあります。

ひとつはディレクトリ管理の改善:CVSの目的と変わらないけど大事な点

わざわざ フォルダ構成全体を  _new 付けてコピーして管理したり、 _old や_20140930などもちろん日付で管理しなくても、取り込み等ができるようになっていると思います。

もうひとつは、スナップショットの作り方やマージの仕方です。確認のためだけでなく、元に戻せるようにしつつ新しい物を取り込めるようになりました。詳しくは次のセクションで話します。

ひとつ目はディレクトリ構成そのままに、でも危なくないように確認したいということだと認識しています。その確認のポイントが次のことです。

  • diff で既存と確認
  • コンフリクト時に、既存だけでなく、その修正した前の版と確認
  • マージしたり環境を作るとき、コピーする。そこにはリスクが伴う

これらがディレクトリ上でファイルの差分管理単位、ステージングの方法が解決のための方法です。

ディレクトリ構成はいじらず、手間いらずのまま、ちゃんとローカルで確認できる。しかも変更単位に合わせて随時候補を上げておくこともできるし、diffも取りやすいステージ環境があります。変更単位にコミット。これがgitのローカルのワーキングとレポジトリの管理単位です。

設計時に考えていくポイント

考え方はこんな感じ。↓

ローカルとレポジトリ(ローカル)に2つのコピーは必要。

レポジトリが正式版。ローカルをWorking Directory として、いろいろいじるのが前提。

うまく言ったらコミットする流れにする。

ローカルを全てコミットするのは、もちろんありえないけど、
指定するのが面倒だし、unixコマンドを使ってまとめてコミットすると間違う時もある。

そのためコミットする直前で確認できるようにしたい。もちろんディレクトリなどのコピーとかしないで。

ステージング領域も必要だな。コミットする候補を登録しておいて、diff確認できればOK.

コミット単位は、変更単位にあわせるので、複数のファイルをのせることもあるな。
一個ずつcommitするのは危なすぎるし、細かすぎる。

作業サイクル

以上の考えで使用するときのサイクルは以下のようになり、それぞれgitコマンドが用意されています。おそらく。。。しかも大抵がデフォルトでコマンド量少なく使えます。

  1. レポジトリから今のプロジェクトの今のブランチである今のポイント(最新:HEADなど)をローカルに持ってくる
    • git checkout
    • git log
  2. ローカルでいじる
  3. 一部ステージングにあげておく
    • git add, git rm, git mv
  4. ローカルでいじる
  5. ステージングに上げ直したり追加する。
    • git add
    • git rm --cached 
  6. コミット直前に上げるファイルの過不足を確認し、コードも確認しておく。
    • git status(編集したけどステージングしていないものも含めてcommit予定内容がわかる。)
    • git diff(あげ忘れ確認)   git diff --cached(コミット差分内容確認)
  7. OKならコミットする。
    • git commit

 

 その5へ続く

Delicious にシェア
Digg にシェア
reddit にシェア
LinkedIn にシェア
LINEで送る
email this
Pocket

296 views.



コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です