windowsについての、ご指摘、ご意見、ご質問、文句はこちらへどうぞ!でもやさしくしてね。AMなんか誰も何も書いてくれないので、さびしいので自分で書きます。(;_;)改めて読み直してみると、結構わかりづらいところが沢山ありました。時間があいて忘れてから見ると、気づきますね。書き直したいけど、時間が無いなあ。PM現在バージョン管理ソフトを検討しており、subversionやgitなどをいろいろ調べています。こちらのサイトを拝見させていただき、参考にさせていただいてます。運用上で、不明な点があるので失礼ながら質問させてください。当方は以下のようなプログラム開発業務でのバージョン管理ソフトの利用を考えております。1顧客からソースコード一式を受領する。21をベースに修正/開発をする。3顧客へリリース(ソース一式)43のソース一式に顧客の変更を加えたソース一式を受領→マージ54をベースに修正/開発6顧客へリリース(ソース一式)上記が大まかな流れですが、これを繰り返します。バージョン管理ソフトの機能が発揮できるのではないかと思います。ここで1や4でさまざまなタイムスタンプのソースを受領します。何も変更がないものに関してはタイムスタンプが変わらないのがベストだと思います。リリース時にエクスポートなどを利用してソースを梱包した時に、エクスポートした時のタイムスタンプに更新されているようです。顧客からするとタイムスタンプが変わってるので変更の有無を気にしてしまい、混乱を招くように思います。いうツールはファイルの内容を管理をコミットの日時で行うことはわかりますが、エクスポートしたファイルを現在の日時に更新されると問題があるようにおもいます。みなさんはどのように運用されているのでしょうか。何か、よい方法はないでしょうか。機能を理解しきれていないので使い方が間違っているのかもしれませんが、助言をいただけると幸いです。PM投稿ありがとうございます。投稿ですので、うれしいです。記事にも書いてありますが、Git自体はファイルのタイムスタンプを管理していないので、エクスポートするとその時点の日時になってしまうのでしょうね。タイムスタンプの保持は、リリース用のリポジトリを一つ作り、そこにチェックアウトしてからリリースすれば可能だと思います。そのリポジトリはずっと残しておく必要がありますが、この方法なら、変更があったファイルのみタイムスタンプが変更されます。この方法でもお客さんから貰ったソースのタイムスタンプと同じになるとは限らないですね。変更の無いものはお客様から頂いた時のタイムスタンプと同じになるようにするには、お客様から頂いたファイルを登録するときに使ったリポジトリを取っておいて、リリース時にはそこにチェックアウトして、リリース、とやれば何とか出来そうです。ややこしいので、お客さんにもGitで管理してもらい、ネット上のリポジトリで共有するか、パッチでやり取りして、タイムスタンプは変更の有無とは関係ない、と出来れば、一番分かりやすいかもしれません。お客様があることなので、自由にはならないと思いますが、Gitなら比較的ネットでの共有がやりやすいと思います。PM早速の返事ありがとうございます。一人で悩んでいたので非常に助かります!>タイムスタンプの保持は、リリース用のリポジトリを一つ作り、>そこにチェックアウトしてからリリースすれば可能だと思います。>そのリポジトリはずっと残しておく必要がありますが、この方法なら、>変更があったファイルのみタイムスタンプが変更されます。・リリース時は[リリース用]フォルダでチェックアウトすれば[リリース用]フォルダに最新の内容と差分があったファイルのみ更新される。このフォルダ内のソース一式をお客様にリリースすればよい。・お客様が更新したソース一式を再度頂いた場合も既存の[リリース用]フォルダに上書きして、同様の作業を行う。これならうまくいきそうですね。お客様にGitを利用してもらうのは他にも数社関係するため、少し敷居が高いかもしれないですね。提案したら気に入ってくれるかもしれませんが。上記方法で駄目なら、更新したファイルのみをGitで管理し、リリースの際はお客様に頂いたソース一式に更新したファイルを手動で上書きして梱包するしかないかと思っています。(←Gitの有用性が薄まってしまっていますが。いうことでしょうか?そう、そうです!文書だとわかりにくいかと思いましたが、わかっていただけてうれしいです。>お客様にGitを利用してもらうのは他にも数社関係するため、少し敷居が高いかもしれないですね。Gitは最初ちょっと敷居が高いので、ある程度の管理レベルと管理意識のある会社じゃないと難しいかもしれないですね。>提案したら気に入ってくれるかもしれませんが。AM「ソーシャルコーディング」に興味をもってGitの情報を検索してたどり着きました。説明が非常にわかりやすいですね。PM突然のコメントすいません。私は、現在工場の社内SEとしてラインで使用するプログラムの開発に従事しています。そこで、最近になりプログラムのバージョン管理を行うことになり『TortoiseGit』を使用することになりました。なんとか、インストールに成功してテスト的に私一人が使用して使い方がわかってきたら他の開発者へ展開するような感じで動いていますがすでに3か月ほどやっていますが未だに理解できずネットの中をさ迷い歩いてここにたどり着きました。質問で不躾だとは思ったのですが、質問させてください。この『TortoiseGit』というソフトでは、フォルダごとに個別に管理することは出来ないんでしょうか?というのも、当方の環境では複数のラインがありそのラインごと製造製品ごとに使用しているプログラムが違います。それを管理しようと思って¥開発フォルダ¥ライン1¥ライン1、製造製品1のプログラム¥ライン1、製造製品2のプログラム¥ライン2::というようなディレクトリ構造にしました。この状態で、『¥ライン1、製造製品1のプログラム』でブランチを作り切り替えると『¥ライン1』全体が切り替わってしまって『¥ライン1、製造製品1のプログラム』だけで別ブランチを作ることが出来ません。これでは非効率なので何とか『¥ライン1、製造製品1のプログラム』だけでブランチを作って、切り替えをした時も『¥ライン1、製造製品1のプログラム』のみが別ブランチに移るようにしたいのですが方法はありますか?突然にご質問で大変不躾ではありますがご回答いただけると幸いです。当方の環境としては、OSはWinXP、『TortoiseGit』のバージョンは『TortoiseGit-1.8.16.0-32bit.msi』を使っています。ラインで使用しているプログラムがWinXP下でしか動作しないのでこのような環境になっています。一応NASサーバを入れてそこにプログラムのバックアップを取るように環境を作りました。長文、乱雑な質問になってしまいましたがご回答何卒よろしくお願いします。メールありがとうございます。Gitの実装の一つであり、基本的な考え方や機能は、Gitとまったく同じです。何か特別な機能があるわけではありません。Treeでも、同じリポジトリをそのまま操作できます。考え方は、リポジトリ全体のバージョンを管理する、というものですので、一部のフォルダを分けて管理するという考えはありません。別のリポジトリにしてしまうのが一つの方法です。ライブラリなど共通部品があると想像できるので、リポジトリを分けるのは現実的ではないかもしれません。#細かくいうと、SubTreeという機能があって、ライブラリ等の共通リポジトリを別のリポジトリに#取り込んで管理するという方法があるのですが、これは結構ややこしいので、今回のケースには#当てはまらないかもしれません。一般的な使い方だと思います。複数人の開発者がいるのなら、開発者数分の非センターリポジトリを作って運用することになります。ライン1用もライン2用もどちらのフォルダも入っています。修正するのは、ターゲットのフォルダ内のものだけ、という事になります。ライン1用リポジトリといっても、ライン2用リポジトリとなんら変わるところはなく、単に運用上、修正するターゲットが違う、というだけで、ライン2用でライン1のプログラムを修正してもまったく問題となることはありません。(ただし、同じファイルの同じ場所を修正すると、マージの時に競合(コンフリクト)が発生します。このあたりが大変柔軟に運用できるので、優れた点でもあるのですが、とっつきにくい点でもあると思います。ご参考になりましたら、幸いです。コメントをキャンセルメールアドレスが公開されることはありません。WordPress.。