＞この『TortoiseGit』というソフトでは、フォルダごとに個別に管理することは
＞出来ないんでしょうか？

まず、TortoiseGit は、Gitの実装の一つであり、基本的な考え方や機能は、Gitとまったく同じです。
TortoiseGit だから何か特別な機能があるわけではありません。　
そのほかのGitのツール、例えば Source Treeでも、同じリポジトリをそのまま操作できます。

git の考え方は、リポジトリ全体のバージョンを管理する、というものですので、一部のフォルダを
分けて管理するという考えはありません。

さて、お問い合わせの件ですが、もしライン１とライン２が全く関連を持っていないのでしたら、
別のリポジトリにしてしまうのが一つの方法です。

ただおそらくは、ライブラリなど共通部品があると想像できるので、リポジトリを分けるのは
現実的ではないかもしれません。

＃細かくいうと、SubTreeという機能があって、ライブラリ等の共通リポジトリを別のリポジトリに
＃取り込んで管理するという方法があるのですが、これは結構ややこしいので、今回のケースには
＃当てはまらないかもしれません。（私はよく使っています）

ライン１とライン２の更新が 同時期に行われないのなら、おそらく苦労されていないと思うので、
ライン１とライン２の更新が同時並行的に行われる（複数人での開発も含めて）と考えると、

　センターリポジトリ
|
+–> ライン１用リポジトリ
|
+–> ライン２用リポジトリ

の様にして、ライン１の変更はライン１用リポジトリで行い、ラインに２の変更はライン２用リポジトリで行い、
完了後に、各リポジトリでmasterにマージ後、センターリポジトリにプッシュする、というのがおおざっぱですが、
一般的な使い方だと思います。

もし複数人の開発者がいるのなら、開発者数分の非センターリポジトリを作って運用することになります。

この場合、 ワーキングディレクトリには 、ライン1用もライン２用もどちらのフォルダも入っています。
修正するのは、ターゲットのフォルダ内のものだけ、という事になります。
つまり、ライン１用リポジトリといっても、ライン２用リポジトリとなんら変わるところはなく、単に
運用上、修正するターゲットが違う、というだけで、ライン２用でライン１のプログラムを修正しても
まったく問題となることはありません。（ただし、同じファイルの同じ場所を修正すると、マージの時に
競合（コンフリクト）が発生します。）

Git はこのあたりが大変柔軟に運用できるので、優れた点でもあるのですが、とっつきにくい点でもあると思います。

ご参考になりましたら、幸いです。

そう、そうです！
文書だとわかりにくいかと思いましたが、わかっていただけてうれしいです。

>お客様にGitを利用してもらうのは他にも数社関係するため、少し敷居が高いかもしれないですね。

Gitは最初ちょっと敷居が高いので、ある程度の管理レベルと管理意識のある会社じゃないと難しいかもしれないですね。

>提案したら気に入ってくれるかもしれませんが。。。

是非ご提案を！

では！

>タイムスタンプの保持は、リリース用のリポジトリを一つ作り、
>そこにチェックアウトしてからリリースすれば可能だと思います。
>そのリポジトリはずっと残しておく必要がありますが、この方法なら、
>変更があったファイルのみタイムスタンプが変更されます。

こういうことでしょうか？
・[リリース用]フォルダでリポジトリを作成
・[リリース用]フォルダにお客様から頂いたソース一式を保存
・リモートリポジトリにファイルを追加
・各作業者は、このリモートリポジトリをクローンして利用
　→各自の作業ツリーでプルするとソース一式が現在のタイムスタンプでコピーされる
　→内容変更があったものをプッシュしてリモートリポジトリに反映
・リリース時は[リリース用]フォルダでチェックアウトすれば
　[リリース用]フォルダに最新の内容と差分があったファイルのみ更新
　される。
　このフォルダ内のソース一式をお客様にリリースすればよい。
・お客様が更新したソース一式を再度頂いた場合も既存の[リリース用]フォルダ
　に上書きして、同様の作業を行う。

これならうまくいきそうですね。

お客様にGitを利用してもらうのは他にも数社関係するため、少し敷居が高いかもしれないですね。
提案したら気に入ってくれるかもしれませんが。。。。

上記方法で駄目なら、更新したファイルのみをGitで管理し、リリースの際は
お客様に頂いたソース一式に更新したファイルを手動で上書きして梱包する
しかないかと思っています。(←Gitの有用性が薄まってしまっていますが。。。)

記事にも書いてありますが、Git自体はファイルのタイムスタンプを管理していないので、エクスポートするとその時点の日時になってしまうのでしょうね。

タイムスタンプの保持は、リリース用のリポジトリを一つ作り、そこにチェックアウトしてからリリースすれば可能だと思います。そのリポジトリはずっと残しておく必要がありますが、この方法なら、変更があったファイルのみタイムスタンプが変更されます。

でも、この方法でもお客さんから貰ったソースのタイムスタンプと同じになるとは限らないですね。変更の無いものはお客様から頂いた時のタイムスタンプと同じになるようにするには、お客様から頂いたファイルを登録するときに使ったリポジトリを取っておいて、リリース時にはそこにチェックアウトして、リリース、とやれば何とか出来そうです。

でも、ややこしいので、お客さんにもGitで管理してもらい、ネット上のリポジトリで共有するか、パッチでやり取りして、タイムスタンプは変更の有無とは関係ない、と出来れば、一番分かりやすいかもしれません。お客様があることなので、自由にはならないと思いますが、Gitなら比較的ネットでの共有がやりやすいと思います。

運用上で、不明な点があるので失礼ながら質問させてください。
当方は以下のようなプログラム開発業務でのバージョン管理ソフトの利用を考えております。
①顧客からソースコード一式を受領する。
②①をベースに修正/開発をする。
③顧客へリリース(ソース一式)
④③のソース一式に顧客の変更を加えたソース一式を受領→マージ
⑤④をベースに修正/開発
⑥顧客へリリース(ソース一式)
上記が大まかな流れですが、これを繰り返します。
まさにバージョン管理ソフトの機能が発揮できるのではないかと思います。

ここで①や④でさまざまなタイムスタンプのソースを受領します。
新たに修正を行うファイルに関してはタイムスタンプが更新されてもよいのですが、
何も変更がないものに関してはタイムスタンプが変わらないのがベストだと思います。
リリース時にエクスポートなどを利用してソースを梱包した時に、エクスポートした時のタイムスタンプに更新されているようです。顧客からするとタイムスタンプが変わってるので変更の有無を気にしてしまい、混乱を招くように思います。

こういうツールはファイルの内容を管理をコミットの日時で行うことはわかりますが、エクスポートしたファイルを現在の日時に更新されると問題があるようにおもいます。みなさんはどのように運用されているのでしょうか。
何か、よい方法はないでしょうか。十分機能を理解しきれていないので使い方が間違っているのかもしれませんが、助言をいただけると幸いです。

改めて読み直してみると、結構わかりづらいところが沢山ありました。
書いている最中は、全部頭に入っちゃっているので気づかなかったけど、
時間があいて忘れてから見ると、気づきますね。
書き直したいけど、時間が無いなあ。